Exploring the Hierarchical Security model in CRM 2015

I kicked off the new working year by starting on a new Microsoft Dynamics CRM 2015 project. I've been learning about the new features and in this vlog I am covering the new Hierarchical Security model. This is based on what I have discovered so far and I'll probably learn more about it as I work in other CRM 2015 projects so keep an eye for future related vlog's.

Trial and error over the past few years have made me understand what is easy and difficult to achieve with Business Units, Security Roles, Field Security Profiles and Access Teams in Microsoft Dynamics CRM. One of these scenarios is accounting for visibility of records from a certain level without giving too much access. For example, I am a Membership Director and I'd like to see what is happening with the Membership Reps but I don't need to update information on these Memberships. But I do need to edit the Quotes for Corporate Memberships that the Corporate Membership Manager is responsible for. The concept of Hierarchical Security accommodates this scenario which is explained in my walkthrough.

Righto, here's my thoughts in writing if you couldn't understand what I was presenting.

The following is the layout of a Membership team/department.

I have just used the standard security Sales Person and Sales Manager role where the Read Privilege is enabled to User access only (refer to my vlog). This is for the purpose of demonstrating how Hierarchical Security can be used when combined with security role where User access is enabled as the Read Privilege.

Manager Hierarchy
Manager Hierarchy is for an end user that has directly associated end users to have the ability to create, read, edit, append and appendto access of records owned by the associated end users. For example, I am a Retail Membership Manager and I have the access to any end user who I am a manager of. The Retail Membership Manager can edit the membership records owned by the Retail Reps as the Retail Manager is the direct manager of these individuals.

It can also provide a manager in a higher level to have read access to the end user records that are not associated directly to the manager, AS LONG AS there is another user who is the manager of these end user records and who is also directly reporting to the manager in the higher level. For example, the Membership Director has the ability to see the records owned by the Retail and Corporate Reps but the Membership Director canont edit these records. The Membership Director can see these records because the Membership Reps report to the Membership Manager who directly reports to the Membership Director.

Position Hierarchy
Next up is Position Hierarchy. This one took me a while to get my head around but I think I now get it. You can associate end users to a position which can give them access to records within the same "ancestor path." It uses the parent-child concept.

End Users in a higher position will only have read access of records owned by end users that do not report to their position AS LONG AS these end users is associated to an end user that is in a child position directly linked to the higher position.

During this exploration I found out the following:

• an end user can only have one manager (applies to manager hierarchy)
• an end user can only have one position (applies to position hierarchy)
• you can have many child positions associated to one parent position (applies to position hierarchy)
• an end user from another business unit can be added to a parent position if they need to create, edit, append and appendto access to records at that level (applies to position hierarchy)
• the highest position does not need a parent position, but all lower positions require a parent position otherwise records aren't visible to end users in a higher position. I know this sounds like the obvious but it wasn't for me as I was used to modelling with Security Roles. It took me a long time to workout why I wasn't able to see lower level records (applies to position hierarchy)
• a position can have many end users that are associated to different Business Units. For example the Membership Managers position can have two end users where one end user is linked to the Membership Business Unit and the other end user is linked to the Marketing Business Unit
• an entity view such as Open Memberships will display the records, there is no need to add a criteria to show records where Owner is equal to XXXXX. This was previously required to see records owned by a Team or a new custom view was required to see records based on the access team an end user is linked to (if access teams is used).
• audit history recognizes if a change has been made by a user that has been enabled for hierarchical security
• the dashboards and advanced find also will display records owned by other users that are direct or in-direct reports to the user that has been enabled for hierarchical security.

The one odd thing I found was that if "Organisation" access was enabled in the Read privilege for an entity (eg. Opportunity) the hierarchical security did not apply. Any user that had the manager or position hiearchy enabled could only Read records when he/she was meant to have read, edit append and appendto access. I'm not sure whether this is a bug but this is what I discovered.

This was a learning curve but I'm glad I went through it because now I'm thinking twice about how to structure end users. I have a better understanding of Hiearchical Security modelling in Microsoft Dynamics CRM and I'm sure I'll learn more when combining the other methods of security. I hope you learnt something from me and hopefully this will get you thinking on how to structure end users in Microsoft Dynamics CRM 2015.

Toodles!