Hierarchy Security Tag

Heirarchy Secutity

All about Hierarchy Security in CRM 2015

In our previous blog, we have discussed Hierarchy Visualization, and in this blog we will discuss Hierarchy Security.

 

Below I have explained some brief and important points about the Hierarchy Security.

  1. It is an extension of the Dynamics CRM Security Model.
  2. It offers more granular access to records.
  3. It reduces maintenance costs, because it is easy to maintain and does not require a large number of Business Units.

 

The hierarchy security model is an extension to the existing Microsoft Dynamics CRM security models that use business units, security roles, sharing, and teams. It offers more granular access to records for an organization and helps to bring the maintenance costs down. For example, in complex scenarios, you can start with creating several business units and then add the hierarchy security. This will achieve more granular access to data, with far less maintenance costs, than a large number of business units may require.

 

Basically Hierarchy Security is divided into two parts.

  • Manager hierarchy
  • Position hierarchy

 

Important points about Manager hierarchy

  1. Based on the direct reporting security model.
  2. This is established based on the Manager Field of the System user.
  3. Managers are able to access the data of their subordinates. And able to perform work on behalf of them.
  4. A manager must have at least the user level Read privilege on an entity, to see the data of their subordinates.
  5. Only restricted to the BU.

 

Important points about Position hierarchy

  1. Not based on direct reporting structure, as Manager Hierarchy.
  2. We can define various Job Positions & arrange Position hierarchy based on that Position. It means users at a higher position can access the data of lower positions.
  3. The direct higher positions must have Read, Write, Update, Append, AppendTo access to the lower positions’ data in the direct ancestor path. The non-direct higher positions, have Read-only access to the lower positions.
  4. Not restricted to the BU.
  5. With the Position hierarchy security, a user at a higher position can access records owned by a lower position user or by the team that a user is a member of.
  6. In addition to the Position hierarchy security model, the users at a higher level must have at least the user level Read privilege on an entity to see the records that the users at the lower positions have access to.

 

The Position hierarchy is *not* based on the direct reporting structure, like the Manager hierarchy. A user doesn’t have to be an actual manager of another user to access user’s data.

 

But based on the position, higher position’s user can access the data of the lower position’s users.

 

If we take an examples of the positions that are given into the below image. Then you can see CEO is on the higher position and VP of Sales and VP of Service is on the lower position. It means, the user at CEO’s Position can access the records of the users that are into the VP of Sales and VP of Service positions.

D-blog-2-1
The Manager Hierarchy is worked based on the Manager Field of the user. As shown in the below screen, Adam is the manager of the Ben, Brendan, and Chris.

D-blog-2-2
Hence, if we setup the Manager Hierarchy, then Adam can access the data of Ben, Brendan, and Chris.

 

Note: With the Position hierarchy security, a user at a higher position has access to the records owned by a lower position user.

 

In addition to the Position/Manager hierarchy security model, the users at a higher level must have at least the user level Read privilege on an entity to see the records that the users at the lower level.

 

How to enabled Hierarchy Security:

 

To set up the security hierarchy, you must have an Administrator security role.

 

The hierarchy security is disabled by default.

 

To enable, go to Microsoft Dynamics CRM > Settings > Security > Hierarchy security and select Enable Hierarchy Modeling. After enabled the hierarchy modeling, choose the specific model by selecting the Manager Hierarchy or Custom Position Hierarchy. All system entities are enabled for hierarchy security out-of-the-box, but, you can exclude selective entities from the hierarchy.

D-blog-2-3
Set the Depth to a desired value to limit how many levels deep a manager/position has a Read-only access to the data of their reports.

D-blog-2-4


NOTE: To make any changes in Hierarchy security, you must have the Change Hierarchy Security Settings privilege.

For example, if we take an example of the following image.

D-blog-2-2

And set the Depth = 1 in Manager Hierarchy Security settings, then Adam can only access the records of Ben, Brendan, and Chris. And in case if we set the Depth = 2, then Adam can access the records of Cynthia as well as Ben, Brendan, and Chris.

 

Set up Manager and Position Hierarchies:

 

The Manager hierarchy is easily created by using the manager relationship on the system user record. You use the Manager (ParentsystemuserID) lookup field to specify the manager of the user.

 

If you have already created the Position hierarchy, you can also tag the user with a particular position in the Position hierarchy. In the following example, the sales person reports to the sales manager in the Manager hierarchy and also has the Sales position in the Position hierarchy.

D-blog-2-5

To add a user to a particular position in the Position hierarchy, use the lookup field called Position on the user record’s form.

 

To create a Position hierarchy, go to Microsoft Dynamics CRM > Settings > Security > Positions. For each position, provide the name of the position, the parent of the position, and the description. Add users to this position by using the lookup field called Users in this position. Below is the example of the Position hierarchy with the active positions.

D-blog-2-6

In the below screen, I have given an example of the enabled users with their corresponding positions.

D-blog-2-7

Use hierarchy security models in conjunction with other existing security models for more complex scenarios. Avoid creating a large number of business units, instead, create fewer business units and add hierarchy security.

 

Performance considerations:

 

Keep the effective hierarchy security to 50 users or less under a manager/position.

You can use the Depth setting to reduce the number of users in hierarchy security.

 

I Hope this has helped you to understand Hierarchy Security!!!