CRM2015 introduces a new dimension to the already robust security model called ‘hierarchy security’.  Firstly, if you have a fairly ‘open’ security model whereby most users have global access or parent/child business unit access to records, then this feature will give no benefit. This is all about making records visible to managers from their subordinates or from users in lower ‘positions’ to those in higher positions.

Hierarchical security comes in to its own where there is a strong need to restrict records so that the normal situation is for users to only see records which they own or have been shared (directly or via team ownership) with them. Hierarchical security when used in conjunction with the ‘user owned’ privilege granted via a security role allows two scenarios to be easily met where traditionally, a combination of many business units and complex sharing would have been the only way to achieve it.

1.       Enable managers to read/edit their direct report’s records and read the records of users in-turn subordinate to those.

2.       Enable users in a certain job position to read/edit records owned by users in a subordinate job position and read records owned by users in a job position that is in-turn subordinate to that.

Hierarchical security when activated works on a principle of ‘depth’. Depth means how many ‘hops’ down through the user > manager relationship chain a user can see OR how many job positions down the position chain a user can see.


Security now has its own tile in CRM2015 (hurray!) and within this page, there are two new options ‘Hierarchy Security’ and ‘Positions’.


Hierarchy Security has a master switch to enable it, by default it is turned off. Once pressed, the user can specify a ‘Depth’. As mentioned above, depth controls the number of levels that record access is granted between users linked via the manager lookup or job positions. Pay attention to depth as it can have a performance impact if set too high (see the notes section at the end of this article).

Either manager hierarchy OR custom position hierarchy can be selected at this point. The ‘Configure’ links either take you to the user view (manager hierarchy) or the positions view (custom position hierarchy).

The final configuration option it to omit certain entities from the hierarchical security. This may be of use if for example all users have global access to contacts thus rendering hierarchical security ineffective or maybe if certain entities should continue to remain private across the hierarchy.

It’s important to note that business units have no effect on hierarchical security, it doesn’t matter where the users sit in the business unit hierarchy, what is important is that ‘user owned’ access is in use.

Configuring Managers

To configure managerial security, your users must be linked together via the ‘manager’ field on the user record. Platform checks are performed when the manager is changed and for this reason the lookup is disabled and the ‘Change Manager’ option must be selected from the command bar. Only users who live in the same business unit or business units directly linked higher up the business unit hierarchical chain can be selected.


Here, the user Marvin Minnion has manager Mike Middleman selected. Mike Middleman has Barry Bossman configured as his manager.


As your users are configured with ‘managers’, you will see an icon appear to the left of their full name that allows you to jump to the hierarchy visualisation which is another new feature in CRM2015.



Configuring Positions

Positions can be created via Settings > Security > Positions and represent a job role to allow multiple users to be assigned to it. Essentially, it is a broader approach to the managerial model so instead of a single manager viewing records owned by their subordinates, a group of users who live in a higher position would see all records owned by users who live in the subordinate position.


A position must have a name then optionally, linked to a parent position. Finally, users are added to a position. A user may only occupy one position. Users can be linked to a position either via the user sub-grid on the position record, or via the ‘Change Position’ option or ‘Position’ lookup field on the user record.

TIP: create positions from the ‘top down’. That way you will be able to select the ‘parent position’ as you create the lower positions.


Here, I have three positions, sales team, team leaders, and Managers. We can view the hierarchy again by clicking the icon to the left of the Name column.


Managerial Hierarchy in more Detail

In the illustration below we have a three level business unit model. Hierarchical security transcends business units however so the example could achieve the same result with a single business unit. The black arrows indicate which users manage which users. The following assumptions are made; ‘Depth’ is configured to 2, the hierarchy model is set to Manager, and all users have a security role that grants ‘user level’ privilege to the Account entity.


Let’s assume all users own one account record. The user in the ‘Directors’ business unit manages everyone in the managers business unit who in turn manage everyone in the sales and service teams so they would see all accounts from all users (12 records in total). They would only be able to edit records owned by their direct reports, so in this case, the four users in the ‘managers’ business unit. The ‘Red’ manager would be able to see and edit the records owned by the ‘Red’ users in the sales team. They would not be able to see records owned by other managers or the other manager’s direct reports.

To achieve this in CRM2013, each ‘manager’ would have needed their own business unit along with a business unit for their subordinate users. With many teams and managers, this would quickly get complicated.

Custom Position Hierarchy in more Detail

In the illustration below we again have a three level business unit model. As stated before, hierarchical security transcends business units so the example illustrates how a higher degree of positional complexity could be overlaid with the business units.



We have four positions configured in this example. Orange users belong to the ‘Operator’ position, green users belong to the ‘Team Leader’ position, red users belong to the ‘Area Manager’ position and finally blue users have the ‘Director’ position.

The ‘blue’ users would be able to see all accounts owned by the red, green and orange users and edit the ones owned by the red users. Interestingly, in this example, the blue user in the managers business unit would see the records owned by the red users but the red users in the same business unit would not see the blue user’s records. Red users would be able to see and edit records owned by the green users, and view records owned by the orange users. Finally, the green users would be able to view & edit records owned by the orange users.


Notes and Take Away Points

·         Hierarchy security works only where all users in the hierarchy have ‘user owned’ privileges to access records. Nothing changes if the manager/user in a higher position has global access, business unit or parent/child business unit access.

·         For both Managerial and Custom Position modes, Read/write access is given one level below (this includes share, append, and append to). Read access is granted two levels+ below.

·         If a child user to a manager or user in a subordinate position has global, business unit or parent/child business unit access to records, that access does NOT inherit up the hierarchical security tree. Only records OWNED by the subordinate user OR owned by a team in which the subordinate user belongs are granted access to the manager/users in a parental position

·         The ‘Depth’ setting can impact performance if set too high. This depends on how many users you have ultimately. The rule of thumb given by Microsoft is try to keep the depth to a level where less than 100 users are exposed to the manager/position. This has other variables however such as the number of records contained in an entity, number of teams, and number of users in the system (not to mention hardware for on-premise deployments) so it is important to test and amend the depth accordingly to suit access and performance expectations.

·         Filtered views support hierarchy security.

·         Offline Synchronisation in the Outlook client supports hierarchy security.

·         New operators are available in advanced find that show records granted via the hierarchy security ‘Equals Current User Or His Reporting Hierarchy’ and ‘Equals Current User Or His Teams Or his Reporting Hierarchy and Their Teams’.



Hierarchical Security is certainly an interesting addition to the existing model and will give the consultant/architect another option to meet the requirements of those projects where secrecy and team driven competition within the user base is paramount. However, for deployments where the dissemination of knowledge across the business is key or there are no legal or internal pressures to keep records hidden from other users or groups of users, this feature will not be relevant.