Single/Multiple hierarchies in IRM

[Kass3m]

Do any customers have multiple entity hierarchies maintained:  one for Risk, a separate one from Audit and SOX etc. 

or do y'all maintain one hierarchy for different areas?

The use case is everyone has different source systems: and relationships need to maintained between products, geographies and entities.  

[Community Alums]

Hi @Kass3m ,

It's always advised to use only one Hierarchy, having said that, until you have the table names where you are getting these entities, you are good as you are going to use those tables for creating entity types/ Classes.

Now, the problem you will face is, let's say you have 2 entities having same name but used for different purposes getting used for Risk and Audit respectively, then you won't get the actual rollup of the compliance .

[GlideScript LLC]

Hi Kass3m,

I will try my best to answer your question based on our experience

Mix and Match Method: So, yes, some companies do go down the path of having multiple hierarchies. Think of it like each department having their own recipe book. The Risk team might have a detailed cookbook on handling operational stuff, while the Audit folks are flipping through a ledger-style guide. It's awesome because everyone gets what they need, but oof, it can be a headache to make sure these books don’t end up contradicting each other.

One Big Cookbook: Then, there's the approach where companies use one big, comprehensive book for everyone. It’s like trying to find recipes that everyone at the dinner table will enjoy. This can really streamline things – you know, one source of truth and all that jazz. But, the tricky part? Making sure this big book isn't too complex for some folks or too simple for others...