Share

2nd Day of CRMas: Hierarchical Security

Welcome to Day 2 of our 12 Days of CRMas. In this blog series, we are going to explore the best and brightest Microsoft Dynamics CRM 2015's new features.  Today we'll take a look at the hierarchial security.

You use Dynamics CRM, and you are a sales manager. You want access to all accounts to which your sales team has access. Simple requirement, but in reality fairly complex to deliver. Security roles couldn’t get you there. Sure, you could just give the sales manager Business Unit or organization level permission level, but that would give access to everything in the business unit or organization, which will be more than just your sales team.

Team ownership would not meet this requirement, as you need to have individual sales owners.


So typically this type of requirement would dictate some sort of complex sharing arrangement. Sharing is ok, but it has some issues scaling for performance.

For example, what happens when someone is moved from one position to another position? The sharing must be rebuilt.

Say hello to hierarchical security in Dynamics CRM 2015. Hierarchical security enhances the existing security tools in Dynamics CRM to provide  rollup of security access to records based on organizational or functional hierarchy.

[responsive]image[/responsive]

Manager Hierarchy

Manager hierarchy uses the “Manager” field on CRM user records to determine who access should roll up to. For example, if you have a sales person, you would add the sales manager to the “Manager” field on the sales person, and the Sales Manager would have the Regional Sales Manager in the “Manager” field on her user record. If your security model follows your organization chart, you would want to select this setting.

Position Hierarchy

Position Hierarchy uses a new entity called “Position” to facilitate hierarchies that don’t follow your organization chart. For example, say you have an inside sales team that does lead prospecting. Their organizational manager is the sales manager, but you want their security to roll up to the marketing manager.

Positions are created in the Positions entity, and a position is linked to Its parent position. Users are linked to their position via the “Position” lookup field on user records.

[responsive]image[/responsive]

Note that a user can only have one position or manager. You can’t mix position and manager hierarchy.

Rolling it up

The hierarchical security does not just apply to direct reports—it can go up to 100 levels deep. You will want to set the depth appropriately for your organization. Remember that the higher up in the organization you go, the users are likely to have organization level privileges, so the hierarchical security may  not be as necessary for the CEO as it is for middle management.

What permissions do I get?

The privileges that you have on the record are based on your security role. To inherit access via hierarchical security, the manager must have at least user level read access to the entity.

What record are rolled up?

The records that the manager gains access to are based around the records owned/shared with the lower level users. The following records will apply to hierarchical security:

  • Records directly owned by the users
  • Records shared with the users
  • Records owned by a team on which the user is a member
  • Records shared with a team on which the user is a member.

As you can see, this is a very complete set of scenarios, as it covers the obvious ownership scenarios, but also some of the less obvious, such as when sharing cascades to a user in the case of reparent. It does not depend on the user’s security role. If a salesperson has a security role that gives her read permission on 2,000 records, but she owns 10 records, only the 10 she owns will be granted to her manager.
Why does this matter?

The thing that makes this a big deal is that it vastly simplifies some very complex scenarios. Not only configuring these scenarios, but also maintaining them. In the “old way,” changes in the management hierarchy could be very cumbersome to manage. With hierarchical security, simply moving someone from one position to another will automatically reflect the correct manager security permissions.