Tag Archives: CRM 2015

Using Hierarchy Security along with Roles

Hierarchy Security is an extension to the existing CRM security. It allows a user at a higher position or manager role to access the records owned by the subordinated users or by the team that a subordinate user is a member of, and to the records that are directly shared with the subordinate user or the team that a user is a member of.


However, it does not stop the subordinates from accessing manager’s records if the subordinate’s role permissions allow users to view records on a unit level or higher.

Just remember this before considering implementing Hierarchy Security:

Check the roles and permissions that you have before applying Hierarchy Security and remember that direct higher positions 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’

Lower positions can access higher positions if the lower position (subordinate) has a role with Business Unit or higher access.

Manager Hierarchy

If you have a management structure already in place, Manager Hierarchy may be the best option. You can run an advanced find to see who has a manager and also who has not.  Then check the permission range for those roles.


In addition to the Manager Hierarchy security model, a manager must have at least the user level Read privilege on an entity, to see the reports’ data.

Position Hierarchy

If you don’t have a management structure already in place and\or you just want to give the hierarchical privilege to some user that is not a manager, you can use the position hierarchy model. The position can be assigned to any user independent of the user’s position.

You can find more details here:


Let’s apply the Manager hierarchy too see how that works:

Veronica is a Sales Person on an organization.  On this existing organization, the salesperson role has the following permissions:


When you search for her account records on advanced find you can see all records on her organization because even though she is a report, her role is set to read with organization level range.


let’s change the Salesperson role to user records range.


Now Veronica can only view her own records.


Spencer Low is her manager.


Spencer also had organization level access. Let’s reduce it to user level. This is not necessary if you want the manager to acess data on unit level. I’m just changing it to show that now the manager can view the subordinate records even without role permission


The manager hierarchy now allow spencer to see his records and his subordinate’s.


Now, let’s try the Position Hierarchy

On the structure below, you can observe that the position doesn’t need to match the title and the users doesn’t need to be manager or to have a manager (under the manager field).  Allie Bellew is a manager but here we will give her a subordinate position.


Initially she can view her  records plus the records on her organization because her role has read permission for unit range.


Let’s change her role to read permission with user level access. Now she can only see her records:


Alicia Thomber  has a hierarchical position higher than Allie’s. even with permission to read accounts on her user level, she can also view records of users with “agent” position


This should be useful to entitle some users to be in charge of a department or team and cover up for their peers when necessary.