4 Replies Latest reply on Mar 3, 2017 9:17 AM by philmodjunk

    Novice Assistance

    nickgadna

      Hello everyone,

       

      I am brand new to the forums and brand new to filemaker, although I am somewhat familiar with database systems and logic and have been watching instructional series to learn the program. I am trying to implement an internal application for my church and am having some trouble conceptualizing the data flow in terms of what I am trying to accomplish. A little background...

       

      I am attempting to create a simple checklist that can be utilized for ensuring that items are completed each week that are necessary for either our Wednesday night or Sunday morning services. The checklists will be mostly the same for both service types, but they may have a few slight variations that would require them to be separate data sets. The thought behind creating a system like this is that each member of the staff would complete their specific portion before the service, and then a report could be ran from the office at a certain time to see what items have been completed and what items remain.

       

      So the way that I am envisioning that data flowing is as such:

       

      Staff member opens the app on their phone

      Staff member selects their name from a dropdown menu, and in doing so informs the application of what departmental check list they need to be presented

      Staff member completes their checklist which would simply be a list of tasks in the following format:

      -CHECKLIST ITEM | X YES X NO | Comments: XXXXXXXX

       

      Once the staff member submits their checklist as complete, it would be nice to have an address notified but that is not critical as long as a report can be pulled prior to the service which would summarize the tasks for each department, who completed the task and a timestamp for when that was done.

       

      ----

       

      Pretty simple (at least I think) but I am having trouble thinking through how to structure would be for the tables and the primary key etc.

       

      Right now, I have set up separate tables for the tasks that apply to each department, there is a table for staff and their information, and then I assume there needs to be a "go-between" table that will serve the appropriate tasks list to the appropriate staff member based upon their department.

       

      Apologies if I am not explaining things well, I am just getting started so trying to digest how to create a somewhat non-standard database out of the gate.

       

      Any help would be greatly appreciated, and of course they are wanting me to figure this out by Sunday

       

      Looking forward to learning more on the site and becoming an active member of the community. Thank you in advance for the help!

       

      Nick

        • 1. Re: Novice Assistance
          philmodjunk

          You are going to need to take this one step at a time. First:

           

          I have set up separate tables for the tasks that apply to each department,

           

          Don't do that. Use one table for tasks with a field that identifies the department. This will make the rest of your design simpler as you can set up a portal or a find that pulls up all records for a given user's department from the same table and thus the same layout.

           

          Second, take a moment and think through all the tables that you need. From your description, it sounds like you need at least these tables:

          1. Staff--one record for each staff member. This could include volunteers.
          2. Departments--One record for each department
          3. Tasks--one record for every task that might need to be done prior to a service. A field can designate the department and another can designate one or both services.
          4. Services--you might not need this one, but a place to document anything special about a given service strikes this lifetime church goer as useful
          5. Task_Completion--One record for each task for each service. This is the field where you have a check box to record whether or not a task is completed. It would serve as a "join" between Services, Tasks, and Departments. Setting up the tasks for a coming service would involve picking the tasks needed for that service and creating one matching record in this table.
          1 of 1 people found this helpful
          • 2. Re: Novice Assistance
            nickgadna

            Thanks Phil! I really appreciate the quick assistance I may get this done by the weekend yet

             

            Ill let you know if I run into any trouble but thank you!

             

            Nick

            • 3. Re: Novice Assistance
              nickgadna

              Ok one more question Phil... sorry as I thought about it I realized I had a question on the last point you made. Could you help me understand the task_completion table a bit and how I would use it as a join?

               

              Do I understand correctly that I would use that layout as the primary layout and design my app around it while pulling information from the various tables via portals to present it? Here is a super crude diagram of how I am envisioning the data flow.

               

              Sorry if it gives you a headache

              File Mar 03, 8 33 46 AM.jpeg

              • 4. Re: Novice Assistance
                philmodjunk

                I would link an occurrence of staff to department. I might or might not need an occurrence of staff linked to Task_Completion.

                 

                I might base a layout on Task_Completion, but I could, for different uses, use a layout based on Department or Services with a portal to Task_Completion. If I base the layout on Task_completion, I will need to preform a find or possibly use Go To Related Records to pull up the correct list of tasks to complete for a given user for a given service.

                 

                If I use a portal, at least part of that process is handled by the relationship. A portal filter would then further limit the records shown. For example, a person logs in and are taken to the record for their department on a department layout. A portal on that layout would show all the tasks that should be completed by that department. A portal filter would reduce that list to the tasks for the current service.

                 

                On the other hand, a portal to this table on Services would list all tasks for all departments in the portal. A portal filter could then reduce the list to a smaller set--such as only uncompleted tasks or only tasks for a given department if such is desired.