Syncing Alternate Hierarchies on a Board
Hi,
I am currently working for a model in which we have two different hierarchies, 1 is D1→D5 and other is P1→P5 where D1→D4 and P1→P4 are the same, and D5 and P5 are different. Now I am using two grids on a same Page, 1 having P1 hierarchy and the other having D1 hierarchy, because of this I am seeing to different Page Selectors on the Page one for each hierarchy, now I have a requirement to link them together so that both of them can sync and update Simultaneously instead of selecting them separately. Is there any way to achieve this?
My First Page Selector uses P5 hierarchy with Hide on P5 level, and the 2nd Page Selector uses D5 Hierarchy with Hide on D5 level. I want that if I change the Page selector for 1st, the 2nd grid should automatically update based on the selection rather than having to select again for Page Selector 2.
Is there any solution for the above issue. It is annoying the client as for now he has to update both the Page Selectors separately to check the data.
Answers
-
Hi @Pranjal - You can build custom user filters & use a field card to filter both the grids.
You'll have to write a formula that checks both the relevant P4 member as well as the D4 (You can do it by using a finditem if they are both the same) and then apply this filter.
Include the user dimension in the selection line item as well as the filter module to avoid clicking refresh by the user.
Hope this helps! :)0 -
Hi @devrathahuja Thanks for the response, but if I apply this, the user won't be able to select at the upper levels of the Hierarchy, so for that I will need a new Composite Hierarchy, is there any other way that it could be achieved without changing the structure of the model?
0 -
Architectural question, instead of having two "identical" L1→L4 lists, why not have D5 and P5 rollup to D4?
0 -
@Pranjal - Yes, you can add 4 field cards & the user can select any level & filter the below grid for that.
It'll require some modelling in terms of If L4 is selected & l3 is also selected then show only l3 members & below & so on.0 -
@rob_marshall Great Question Rob, the same thing is in my mind, but the design is as per Client's Requirement and like this only for past 5 years. Need to discuss with the Client Team if now they are ready to switch to just one hierarchy than two as it also adds to the maintenance.
0 -
But if the client wasn't aware they could do that, maybe that is why it was built the way it was. If they did move to one hierarchy with a branch at the bottom, it will help out maintenance, scalability, performance of the actions (only loading one hierarchy), will help out with the UX issues, etc. Also, it would decrease the size of the model as there will be less lists built.
0 -
@rob_marshall They do have different Security Requirements for which we had to separate the two hierarchies from one another. The Personnel using P1 hierarchy can update the P1 hierarchy details only for their particular office, but can view all the details related to D1 Hierarchy Office and should not be able to add to it. P1 hierarchy is for Personnel Hierarchy and D1 Hierarchy is for Non-Personnel Hierarchy. For Example, Program Office Manager should be able to view and add only Program Office Personnel, but should be able to view all the Non-Personnel Data related to any office whatsoever. So, for that reason we have two different hierarchies in place.
0
