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.
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.
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.