Hierarchy Security Modelling in Microsoft Dynamics CRM

Having a complex CRM user security model can prove costly to maintain in order to restrict access and safeguard your database.

Recent versions of Dynamics CRM offered a series of capabilities enabling database administrators to define a security model using security roles, team based management and CRM access based on business units.

In CRM 2015, hierarchical security models have been introduced to reduce the effort in configuring and maintaining database security.

You can configure CRM security based on the user or functional hierarchy.

With these new features there are two ways to access CRM records:

  • Manager Hierarchy: This is based on the user and manager relationship. Manager must be in the same business Unit.
  • Position Based Hierarchy: It has a structure based on the position of users in the organization.

This makes it an easier to maintain model in the event that individual users transfer to a new role as database administrators can simply move a user to different position, or just update the designated manager.

This reduces the update work involved and also allows users to have quicker access to CRM via their new role.

To get started with a Hierarchy Security model database administrators should access this through Settings -> Security:

We’ll firstly focus on the Manager security model to demonstrate the new capabilities.

Manager Hierarchy

As implied, this requires a Manager to be specified in order to establish a hierarchy in the user entity.

Let’s take an example.

4 CRM user profiles have been created:

1. Warren Butler
2. David Brettell
3. Sean Lonergan
4. Will Benjafield

In a basic scenario we could define rules where each user has read / write privileges for their own records only but aren’t granted access permission to access other user’s records.

However, to demonstrate the new managerial hierarchy we’ve defined a security structure that spans three levels.

In the example below Warren is the manager of David, while David is the manager of Sean and Will:

A key feature of the hierarchy security model is that managers have read / write permission for records owned by subordinate child users who are immediately one level below. Managers are granted read only permissions for records owned by any other child users who are placed at a lower level in the hierarchy.

Using our example this means...

  • Warren has read / write access to David and his own record and read only access to Sean and Will’s CRM records as these are more than 1 level below
  • David has read / write access to Sean and Will’s records (& his own records)
  • Sean & Will only have access to their own respective data

You can specify the manager for this security model by selecting the user’s record from list view and click on Change Manager Ribbon button.

The same hierarchy visualization as shown above can be viewed by selecting user’s record and clicking the View Hierarchy ribbon button:

To complete this process go to Settings -> Security -> Hierarchy Security

Tick the box to enable Hierarchy Modeling to activate this model. For this example we’ve selected Manager Hierarchy:

A hierarchy depth controls how many levels this should work across. By default this is set to 3 as per our example but you can adjust this to match your own requirements.

You can also exclude one or more CRM entities from this hierarchy.

By default the security model will apply to all records but for example all users could access Cases if this entity is exempt from the security model.

Once complete the new security model will be enforced when users next log-in to CRM.

Using a simplified example whereby there are just 4 sample account records stored in this CRM database that represent each user named above this will be listed as follows:

Sean can only view his own account. He would also be able to see further accounts for which he is the designated record owner:

Will also will only see his own account.

As line manager for Will and Sean, David has full access to their accounts in addition to all records for which he is the record owner:

Warren heads up this hierarchy and has read access to the account records for all the users in this model. This also includes read / write permissions for records owned by David his immediate subordinate:

Position Based Hierarchy

As an alternative to defining managerial roles CRM can manage user access permissions based on the position of their role.

To start we first need to create Positions in CRM.

This can be found in Settings -> Security -> Positions.

For this example, we’ve created 3 Positions and defined associated Parent Positions.

1. CEO (top level)
2. Sales Manager (child record of CEO)
3. Consultant (child record of Sales Manager)

For the purposes of this example the position of CEO has been assigned to Warren, Sales Manager to David and Consultant to Will and Sean.

These positions can be defined by opening the user’s record and specifying the respective Position on the form.

Or, open the Positions record and add the users to that position.

You can see the Position Hierarchy by clicking on View Hierarchy ribbon button.

As per the manager hierarchy, read/write access is granted to parent positions for the immediate level below of child records. Any child positions at a lower level are shared with Parent position records on a read only basis.

In this scenario:

  • CEO Position has full access to CEO & Sales Manager data and Read Only permission for Consultant data
  • Sales Manager has read / write access to the data at this level and child Consultant data
  • Consultant position has restricted access to data at this position only

To activate this model follow the same process as the manager hierarchy but select the custom position hierarchy model option.

Once saved, CRM records will be accessed relative to the child positions assigned to each user. For this scenario any user with a CEO position will have read/write access to the next level Sales Manager child position and have only read access to the consultant records.

Returning to our earlier example, David has access to child Consultant records owned by Sean and Will in addition to his own record. In comparison Warren has read / write permissions for David's records but read only rights for records owned by Sean and Will's as their child Consultant profile is placed at a lower level in the hierarchy.

More CRM Hierarchies

In previous posts we highlighted how the CRM hierarchy feature can be used to manage products and relationships between accounts as well as contacts.

The new hierarchical security profile is another great example of Dynamics is simplifying previous complex processes without compromised on database security and data protection.

Contact Preact to learn more about using hierarchies in Microsoft Dynamics or any of the latest CRM features.

RELATED - New Adanced Find Operators For Hierarchies