With the release of Dynamics CRM 2015, we now have a new feature called Hierarchical Security. We’re going to look at how we can configure it and take advantage of it. This feature helps us with giving permissions to managers to see their reporting resources records as needed.
First off, we get to the configuration area by navigating to Settings > Security.
As you can see, the navigation has been streamlined a little bit, and items have been grouped in more defined categories. The Security area now includes configurable items related to users, teams and business units management, along with field security configurations, security roles and access teams templates.
The Hierarchy Security configuration is tucked on the right column. Clicking on it presents us with the following options:
Let’s look at each one of these. First off, and the most important step, we have to enable this feature. We do it by checking the Enable Hierarchy Modeling at the top of this form.
Next section allows us to define how we want the security to behave. We have two options here. First off, the simplest one, we can use Manager Hierarchy. This is based on the user’s Manager definition in the user profile.
We define a Manager for a user by going to the user’s profile and selecting the Change Manager option. From the lookup in the pop-up window we select a system user as a manager.
Observe in the user’s view that once a Manager is assigned to a user, the hierarchical visualization becomes available to show the reporting structure.
Clicking on the new icon for hierarchical visualization presents this structure as follows:
Now that we have this configuration in place, all managers will have access to the child records (reporting users) data. But, how is this access working?
In the Manager Hierarchy model click on Configure.
This opens up the users listing we just looked at, and allows us to re-configure the manager reporting structure.
The Hierarchy Depth is set default to 100, but can be adjusted. For example, if we change it to 1, we can only see records of our direct reporting resources going one layer deep. For our example, that means we will only see records owned by James Monroe if we are logged in as Mike Smith.
Settings this value to a larger number allows us to go deeper down the hierarchy.
One thing to be aware of is how this visibility works. The first layer of reports presents us with a full read-write ability to their records, while further layers down we only have read-only access. This allows us to aggregate results based on data from our reports, going as far down the tree as needed.
The next area allows us to configure which record types (entities) this visibility applies to. Basically, we can set a manager to have only access to Leads and Opportunities of their reports, or to all records.
From the screenshot above you can see that here you have access to both system and custom entities (Idea is a custom entity created in this system).
To understand this, let’s look at a few aspect of the configuration, and how this works. First off, let’s look at the security role. Mike Smith is a Senior CSR. He has the Customer Service Representative role assigned to him. Looking at the definition of this role, for the Lead entity, we see that he only has access to read-write to his own leads.
But looking at the managerial hierarchy defined, James Monroe is a direct report to Mike Smith.
Having the Hierarchical Security model configured on Manager Hierarchy now allows Mike Smith to see not only his own Leads, but the Leads of his reporting resources, James Monroe in this case.
Now let’s bring in a new recruit, Hellen.
She is a CSR Assistant, and reports directly to James Monroe.
Increasing the Hierarchy depth from 1 to 2 now allows Mike Smith to see the Leads from not only James Monroe, but also Hellen Johnson.
Opening now a Lead owner by our direct report, James Monroe we can do edits as needed. But since Hellen is not a direct report, but rather a report of a direct report, if we open up a Lead she own, we only have read-only permission.
Until now we focused on the Manager Hierarchy.
Let’s look now at the Custom Position Hierarchy. The concept is quite similar with regards to records access. The difference is that, this time, instead of looking at the direct manager on the user profile, now we can define our own custom role hierarchy. This can be very valuable, as it can be handled at a higher level.
Selecting Custom Position Hierarchy and clicking on Configure takes us a view of a new entity called Positions. Here we can define a structure of standard Positions in the Organization.
Let’s say we have a structure as such:
Observe that this is very similar to the user reports relationship. The difference is that, instead of handling individual users, we can use the Position bucket, which can hold one or more users.
And the end result in the system is similar, whereas a CSR Manager in this case has visibility into the records of his reports as many layers down as defined in the Hierarchy Depth. Also, the CSR Manager will have read-write permission on the records of CSRs (as direct reports), and read-only rights on records of the CSRs reporting resources and their reports, as far down as defined.
Do note that Positions can be manages not only from the Configure option on the Custom Position Hierarchy, but also from the main Security window (Settings > Security).
Hope this helps :)
Enjoy!
thatcrm.com 
Leave a Reply