I don't see a way to create a hierarchy from a table that just shows employee and manager.

Question

Is there a way to handle the recursion for any number of levels, so I could have one table that has:&nbsp;employee&nbsp; &nbsp;managerbill&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; marymary&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;janejane&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; boband from there I can make sure that jane can see the performance review of bill, for example.&nbsp; How can I start with the above table, with any number of relationships, and end with a table that has:employee&nbsp; &nbsp;manager1_&nbsp; &nbsp;_manager2_&nbsp; &nbsp;_manager3_bill&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; mary&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;jane&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bob(As an aside, I have exactly the same problem with serial numbers on parts, that roll up to assemblies with a new serial number, but those assemblies roll together into larger assemblies with a new serial number, with N levels.)All help greatly appreciated!

quickbasecoachd · Answer

A table can be relation to itself. So 1 Manager May have many employees. Except that the managers are actually Employees.

So then the actual relationship is that 1 Employee have many Employees. The field that the system will create called [Related Employee] should be renamed to [Manager] and then it should make sense.

As for Jane seeing Bill, who is two levels down from her, I think that is possible to do.

But having said that, I�m not sure it�s intuative for users when set up that way. There is an arguement for setting it up more traditionally, where each employee has 3 slots called Manager Level 1, Manager Level 2, Manager Level 3.

debbietaylor · Answer

Great to see your name again, Dave.Definitely do the recursive table-to-itself relationship.Just rename fields so your users don't get lost.And, give us a holler at www.cloudbaseservices.comhttps://community.quickbase.com/quickbase/topics/www.cloudbaseservices.com

daviddegraaff · Answer

Thanks for the clue.&nbsp; I'll see how far I can get.&nbsp; Note that the intuitive way you're suggesting doesn't work well with more people.&nbsp; For example, if I move a group to a new manager, it's easy to just update all their managers, but not easy to update everyone all the way up the chain from their new manager.&nbsp; And when a middle manager changes managers, you need to find them all over the place and update their reporting chain.&nbsp; It doesn't scale.

daviddegraaff · Answer

Thanks Debbie - I very well might.&nbsp; I hope you're doing well!

debbietaylor · Answer

A few more thoughts:You should only build one recursive relationship (eg employee to manager).&nbsp; For additional reporting, add look-up fields (eg second level manager.)When you need to change many records, create a report with the records.&nbsp; Use the "More" button in the upper right hand corner of the screen to access the "Search and Replace in this report" feature.&nbsp; See below.Consider getting an extract from your company's HR system OR, better yet, integrate with it.&nbsp; Some changes can then be automated.

Forum Discussion

I don't see a way to create a hierarchy from a table that just shows employee and manager.

6 Replies

Related Content

Managing record access for multiple data levels

Management Hierarchy Filter in a report

Limited 'manage users'/'manage groups' permissions?

Project Management

Reports & Charts - Managing Client-Specific Name Visibility

Recent Discussions

Can I use quickbase actions within the same table?

Question about relationships

Reports & Charts - Managing Client-Specific Name Visibility

Summary Table Question

Google Search is back