Hierarchy Security in Dynamics 365

Dynamics 365 database consists of data about the organization and its various departments. When it comes to the data, its the very important piece of the business and it can be misused in many ways, if it reaches the wrong hands. We don’t need any other fancy reason to make sure that the data is accessible by only those who are supposed to be. Dynamics 365 comes up with a security model which is flexible enough to meet most of real life scenarios in today’s business world. One of the major part of that puzzle is the hierarchy security to control access within the system. In this blog we will discuss about the manager and position hierarchy security model, how to set them up and some performance considerations regarding the same.

As mentioned, hierarchy security model is an extension to the existing security models which uses Business Units, Security roles, teams and sharing of the data. This setup offers more of a granular access to the records and helps us to bring the maintenance cost of the system down. Within this system, we can have two models, manager hierarchy and position hierarchy. While the hierarchy security model provides a certain level of access to data, additional access can be obtained by using other forms of security , such as security roles. Let us look into both of these models briefly.

Manager Hierarchy

This hierarchy security model is based on the management chain or direct reporting structure. You might have already notices if you are familiar with Dynamics 365 user entity/table that we do have an attribute/column to hold the data for the user’s manager. This model uses the same field to establish the manager’s and reports relationship. The manager can access the data that their reports have access to. They are able to perform work on behalf of their direct reports or access information that needs approval. With this hierarchy, a manager must be within the same business unit as the report, or in the parent business unit of the report’s business unit to have access to report’s data. At the same time the manager has only read access to the non direct report’s data while for the direct report it will be full access. Further more, we can limit access of manager’s ability to read the data using the “Depth”. This is used to limit how many levels deep a manager has read access to the data of their report.

1. With this model, a manager has access to the records owned by the user or by the team that a user is a member of, and to the records that are directly shared with the user or the team that a user is member of.
2. When a record is share by a user who is outside of the management chain to a direct report user with read-only access, the direct report’s manager only has read-only access to the shared record.
3. In addition to the role of the manager, (s)he must have at least user level read privilege on an entity to see the report’s data.
4. In order for the manager to see all the direct report’s records, the direct report user must have an ‘enabled’ user status. Manager will not be able to see disabled user’s records.

Position Hierarchy

In contrast to the manager hierarchy, position hierarchy is not based on direct reporting structure. A user doesn’t have to be an actual manager of another user to access user’s data. In an organization there are various job positions and the administrator/business have to arrange them in the position hierarchy. Then we add users to these positions. In this scenario, the user can only be tagged to one position. One position can have multiple users. Users who are part of the higher position have full access to the data of the users at the lower positions, in the direct ancestor path. To the non direct higher position, have read access to the lower positions. Here also, we can limit the access using the depth to limit how many levels deeps a higher position has access to.

1. With this set up, a user at a higher position has access to the records owned by a lower position user or by the team that a user is member of, and to the records that are directly shared to the user or the team that a user is a member of.
2. The users at the higher level must have at least the user level read privilege on an entity to see the records that the users at the lower position have access to.
3. The higher position user can see the data of the lower position if and only if they are in enabled state.

Setting up Hierarchy Security

To set up the hierarchy security system, the user should be a system administrator or customizer in the environment where this needs to be set up. Once they are in the environment, they can navigate to Settings -> Users + Permissions -> Hierarchy Security. This will be disable by default and it can be turned on from Turn on Hierarchy Modelling by selecting Enable Hierarchy Modelling. To make changes in hierarchy security, the user must have the change hierarchy security settings privilege. Once the model is enabled, we have the option to select from one among the hierarchy model we discussed above along with the depth. On both the hierarchy model manager & position, we can set the level for the user via the Manager and Position fields in the user entity/table. To add a user to a position or change the user’s position, we must have Assign Position for a user privilege. Change position button from the ribbon can be used to make any changes to the position of the users. Once the system is set up with a position hierarchy model, its necessary we set up the position hierarchy for the system. This can be done via Settings -> Users + Permissions -> Positions.

1. Considering the performance of the system, its advised to keep the hierarchy to 50 users or less under manager/position. For larger organizations, it may nor be possible in which case we can use the depth to reduce the number of level for read access to 50 or less.
2. Use this models along with the other security models for more complex scenarios. Avoid creating a large number of business units, instead, create fewer business units and add hierarchy security.

As you might have read through about one of the puzzle of Dynamics 365 security model, with the combination of different pieces of this puzzle, we can design complex of the complex security requirements out of the box through configuration of the system. As mentioned in the starting the access to the data and usage of the same is of utter importance to the organizations, don’t take that lightly by simply creating some configuration records in the system. Do proper due diligence and design the model first as per the business requirements. Use all the required pieces of the puzzle and then start creating the records. Being said that, thanks for your time reading and bye until we meet again with another piece of this puzzle.