10 Replies Latest reply on Apr 19, 2013 7:13 PM by debi

    Relationships and Portals

    dscott23

       

      I'm reposting this as a question..I neglected to check that off in time yesterday.(apologies)

      I need to keep a record of when a person has been called...the project number and the disposition (result) of that call. One person can be called several times on a certain project and can be called on multiple projects.

      Thanks.

        • 1. Re: Relationships and Portals
          Mike_Mitchell

          "One person can be called several times on a certain project and can be called on multiple projects."

           

          Sounds like a many-to-many join, right? In which case, you're probably best thinking of this as a join table:

           

          Project  ---<  Call   >---  Person

           

          Each record in "Call" has a project ID and a person ID. You can then put all the data related to each call (such as disposition, date, time, etc.) on the Call record. If you have a library of possible dispositions (such as you seem to), then you'll have a three-way join; each call has projectID, personID, and dispositionID, with corresponding relationships back to the parent tables. A filtered portal can then show you anything you want to see.

           

          HTH

           

          Mike

          • 2. Re: Relationships and Portals
            dscott23

            In my production DB…I have a “person” table that has 10,000 records already in it…each record has a unique ID_Number that is generated by the system whenever a record is created.  So I’ll need to create a “project table that has all of our current projects listed..along with a system generated Project_ID, same for disposition?

             

            Please look at the revised sample file and let me know if I’m on the right track…as this is still a bit hazy.

             

            Thanks, Mike.

             

            Dave Scott

            Research Associate

            The Henne Group

            116 New Montgomery Street, Suite 812

            San Francisco, CA  94105

            d    908.444.8610

            t     415.348.2948

            f     415.348.1770

            c    732.331.2590

            dscott@thehennegroup.com<mailto:dscott@thehennegroup.com>

            www.thehennegroup.com<http://www.thehennegroup.com/>

            cid:image001.png@01CDCCAA.F636DE30

            • 3. Re: Relationships and Portals
              Mike_Mitchell

              Try the attached and see if it doesn't start to make sense.

               

              Mike

              • 4. Re: Relationships and Portals
                debi

                Hi, Dave ;-)

                 

                Mike has put you on the right track, and yes, I think you will need system-generated IDs for projects and dispositions (well, for all your tables).

                 

                A few things I noted:

                 

                1. Disposition as a table is not a requirement, but I think you will need a value list for the disposition types, one way or another. That means either pulling values from a field in the disposition table or else a hard-coded list of values in the value list definition.

                 

                2. You mention "a person can be called..." but your diagram shows uers. I'm guessing these are two DIFFERENT types of people; if so, you'll need separate tables for each.

                 

                3. To look at this most simply, I see the call list as the crux of your system. Each call should should have its own ID, as well as a foreign ID for the project, the caller (user, if #2 is accurate) and the person called - as well as the date and time you show in the diagram. Per point 1, you could add a foreign ID for lilnking to a dispositon table as well - or just have a disposition attribute in the call table.

                 

                4. Your diagram indicates some type of "filtering" by both project and disposition at the top, but the list below it reflects multiple dispositions.

                 

                You will have many options for how users work with data - especially how they enter/pick IDs for related information, and how they interact with the type of reporting screen you've drawn. But the structural issues - key tables and their relationships - need to come first.

                 

                HTH,

                Debi Rubel

                FullCity Consulting

                • 5. Re: Relationships and Portals
                  debi

                  Dave,

                   

                  Thinking more about dispositions - a third option for the value list: use values from the field in the calls table. I do this a lot, using a drop-down formatted field, so that users can pick from and add to an existing list easily. Can help limit users' typos, without forcing them to pick from an existing list; very flexible but works best after there are already some good values entered.

                   

                  A big advantage to the separate table, however, is that it allows you to collect and show more detail. For instance, you could have a disposition (full), an abbreviation, and instructions on when to code something one way versus another, e.g.:

                  NA - No Answer - Code NA if no answer after 10 rings

                  CB - Call back - OK to call back, but did not specify time

                  CBS - Call back scheduled - Call back at scheduled date/time

                  HUDI - Hung up during intro - Unknown person (may or may not have been respondent)

                  RHUDI - Respondent hung up during intro - Confirmed respondent hung up during intro

                  COMP - Complete - Respondent completed survey

                   

                  I've done a bit of call center work (as well as field interviews and even door-to-door for Gallup), so you really got me thinking. Thanks for the flashbacks!

                   

                  Debi Rubel

                  FullCity Consulting

                  • 6. Re: Relationships and Portals
                    dscott23

                    Makes a bit of sense..I was going that way on MY copy while waiting to hear back from you.

                     

                    I added the disposition field and the project field the the main layout, hoping that I would be able to add that information from that page, but no luck.

                     

                    Looking at the diagram from my original post….a portal just displays the information…how do I set it up for data entry..when one of our folks is on the line with say Don Mattingly..they need to see the historical data and be able to append to that.

                     

                    Dave Scott

                    Research Associate

                    The Henne Group

                    116 New Montgomery Street, Suite 812

                    San Francisco, CA  94105

                    d    908.444.8610

                    t     415.348.2948

                    f     415.348.1770

                    c    732.331.2590

                    dscott@thehennegroup.com<mailto:dscott@thehennegroup.com>

                    www.thehennegroup.com<http://www.thehennegroup.com/>

                    cid:image001.png@01CDCCAA.F636DE30

                    • 7. Re: Relationships and Portals
                      debi

                      Dave,

                       

                      To add records directly in a portal, all you need to do is turn on the "allow creation..." option for the relationship (in the Edit Relationship dialog).

                       

                      Debi  Rubel

                      FullCity Consulting

                      • 8. Re: Relationships and Portals
                        Mike_Mitchell

                        Debi's right about portal record creation. However, in the case of join tables, I often create a separate data entry screen for the join records, especially in cases like this, where the join record is a specific entity in and of itself. That way, the user can say, "New Call" and enter all the relevant data in an independent layout.

                         

                        Whatever works best for the solution.

                         

                        Mike

                        • 9. Re: Relationships and Portals
                          dscott23

                          Thanks Deb.  The user in the diagram is the person who is logged into FMP making the entry..so if I were making the entry the log would reflect my name (use either one:-))

                           

                          So the call log would show date and time..the project number....who entered that occurance....and the dispositon

                           

                          So the user (Me) would be looking at a certain persons record..then picking the project number and the result of the call (dispo)

                           

                          A good deal of the time we do have to call and recall people who are already in the DB..and other times we need to ADD a record for a person who we are speaking to for the first time.

                           

                          Glad I got you thinking...MY head is about to explode:-)

                          • 10. Re: Relationships and Portals
                            debi

                            Dave,

                             

                            Not sure from what you've written, but are you trying to use the same layout for both data entry and reporting/filtering? I think it might be easier to use one layout for each. Also, I had expected that data entry would be done from the context of a project, but it sounds ilke you're doing it from the context of a person instead. So some basics might consist of:

                             

                            DATA ENTRY LAYOUT

                            Person detail screen with a portal of calls. Users would navigate to (find) the person before doing entry. Portal would allow for the creation of records. Date and time (or timestamp) and user could be auto-entered (set that up in the calls table field definitions). Users should just have to enter the project and the disposition.

                             

                            REPORTING/FILTERING LAYOUT

                            Probably a layout based on project detail or a global table if you're using one (though this layout could be based on almost anything). Use a global field for the project in the header, and a portal of calls where the project = the global project. Do not allow record creation on this relationship, and sort the portal with date/time/timestamp in descending order. I'm still not clear how the disposition is supposed to filter, given your diagram.

                             

                            HTH,

                            Debi Rubel

                            FullCity Consulting