Recommendation on best way to create hierarchy between client contacts

Question

I had a user request a good feature for my app. They want to be able to pull a report on a contact showing all of the projects they are associated with. This way if they are meeting with a client they can show them an activity sheet of all active projects.

However, they also want this to be work up the hierarchy. For example lets say we have a team of (3) people. Mark is in charge of the entire east coast and Jeff, Ashley, and Jim all report to Mark.

If I pull a report on Jeff's projects I only want to see his. If I pull a report on Mark I want to see any direct projects Mark is working on in addition to Jeff, Ashley, and Jim since they all report to Mark.

So I am thinking I need to take my contacts table and make a relationship to itself with a field. In this case on Mark as the contact I could add his direct reports in the one to many relationship and pull the data. Or should I be creating a field somehow on the contact to identify the supervisor so on Jeff's contact page I would select Mark as his boss.

Once I get the relationship right I am assuming it is a straight forward report but wasnt 100% sure I am going about it the right way.

------------------------------
Ivan Weiss
------------------------------

evanwestbrook · Answer

Ivan,If I understand correctly, it sounds like you have a couple of many to many table situations.

Many Contacts can have many Supervisors, and many Supervisors can have many Direct Reports

Mark could report to both Larry, VP of Sales, and Cindy, VP of Operations

Many Direct Reports can have many Projects, and many Projects can have many Direct Reports working on them

Trucking Accounts can be worked on by Mark and Ashley, and Ashley can be working on Trucking Accounts and Baseball Accounts

With many to many relationships, a "join" table might be more appropriate than relating a table to itself. For example, maybe you would have a "Supervisor Direct Reports" table to track hierarchies, and a "Employee Projects" table to track which employees are on which projects.------------------------------Evan WestbrookPRIME DeveloperHarder Mechanical Contractors Inc.Portland OR------------------------------

evanwestbrook · Answer

Ivan,I think we're on the same page with how Contact Hierarchy would work. I did want to touch on some items behind the recommendation for a second table, as I think this one could go either way. Item 1: Data Structure Best PracticesA good goal for many databases is 3rd Normal Form. Essentially, this just means that the tables in a database are set up such that a piece of data only exists in one place. I should note that this is a "Recommended Best" practice and not "The Only" practice. Design goals should be balanced with business needs for the database. Examples where a database might not be fully "normalized" are typically related to performance (reporting databases, data warehouses, query response times, end user workflows, etc.)&nbsp;QuickBase University has some great notes on this if you'd like more information.Item 2: This use case could go either wayA second table vs. relating a table to itself is sometimes a "to-may-to" "to-mah-to" situation. In the below image, Options 1 and 2 can more or less do the same thing.

We even have some self-related tables like Option 2 in some of our production apps.Item 3:&nbsp; Option 1 vs. Option 2When designing databases and writing code, efficiency, performance, and simplicity are important. Readability, maintainability, and debugability are also important.&nbsp; In my experience, Option 2 relationships in our apps have been difficult to debug and difficult to explain when on boarding new team members. It's less clear what the table relationship does at a quick glace.Option 1 is also closer to 3rd Normal Form, and it gives us a lot of potential benefits: The hierarchy relationships between Contacts exist in a single location. It's more clear to any app users how Contacts are related to each other. It sets the foundation for future business needs (i.e. allowing other tables to use this contact hierarchy.) Updating future Contact Hierarchies (i.e. Bob gets promoted from DM to RVP) is easier.

Here's an example of how you might set it up:

------------------------------Evan WestbrookPRIME DeveloperHarder Mechanical Contractors Inc.Portland OR------------------------------

ivanweiss · Answer

Evan, thanks for the response!&nbsp; not quite right though.&nbsp; I am not referring to an internal hierarchy.&nbsp; I am referring to a client hierarchy.&nbsp; For example our largest client has the following Hierarchy:

President of the Division
Multiple Regional Vice Presidents reporting to the President
Multiple District Managers reporting to each Regional Vice President
Multiple General Managers reporting to each District Manager

So in essence a pyramid type of setup with (4) layers.&nbsp; If I pick any contact towards the top of the list I should be able to see all of their opportunities underneath them.So if I view the President, I see the entire pyramid.&nbsp; If I pick a RVP I get the DM and GM opportunities reporting up to that RVP, etc.------------------------------Ivan Weiss------------------------------

evanwestbrook · Answer

Ivan,Thanks for the clarification. I'm going to assume your client list table is called "Clients."I think an additional table to track hierarchies is still the direction you want to go (maybe a separate table for each hierarchy step if it's going to remain fairly static.) If you relate Clients to Clients, you'll have to add a new table relationship for each additional field (not fun.) Having Parent records automatically know their Children or Grandchildren could get tricky, but once you figure that out, it will be simpler to manage. From there, you can set up report links to display the information your form. Lookup fields counting the total #&nbsp;of Child records for each hierarchy step can then feed form rules to display different aspects of the Client form.​------------------------------Evan WestbrookPRIME DeveloperHarder Mechanical Contractors Inc.Portland OR------------------------------

ivanweiss · Answer

Evan, so I did not quite follow you.&nbsp; The table is called Contacts.I was assuming I could self relate it and just do it that way.But you are saying do a separate table and name it lets say Contact Hierarchy.&nbsp; I am thinking it should relate to the Contacts table twiceThe first one being the Employee and the second one being the Manager?&nbsp; Is that correct?&nbsp; And use that to report out the work since it is linking people?&nbsp; I guess what I was somewhat confused by is each Manager can have several Employees reporting to them.------------------------------Ivan Weiss------------------------------

Forum Discussion

Recommendation on best way to create hierarchy between client contacts

Related Content

difficulty in contacting QB?

Design Recommendation Needed

Contact Form Recommendation

Recommendations on when to delete or archive contacts

Management Hierarchy Filter in a report