Security Nuances with Manager Based Hierarchy in Dynamics 365

Security Nuances with Manager Based Hierarchy in Dynamics 365

Manager Hierarchy was introduced way back with 2015 Online Update 1. And you might be wondering why this blog after years this feature has been introduced?

Well I can assure you, you won’t be disappointed after reading this blog. In this blog I will explain in detail the manager security nuances from my personal experience with project implementations and training. I am not going to explain how Manager security works. I am just going to explain the security nuances and how it works in multiple scenarios.

To explain my point, I have the below data set-up in my environment.

1. Business Unit Set-up

  • Americas –> Child BU of Root BU
  • North America –> Child BU of Americas

2. User Set-up

  • User A belonging to Americas BU
  • User B belonging to North America and reporting to User A
  • User C belonging to North America

3. Created Custom Entity named – Manager Hierarchy Test

4. Security Roles

  • Manager Role – having User level access on all privileges on the entity Manager Hierarchy Test
  • Reportee Role – having BU level access on all privileges on the entity Manager Hierarchy Test

5. User A is assigned Manager role and User B and User C having Reportee Role

So Manager Hierarchy affects which record? To put in my words

  • Owned by Reportee
  • Shared to Reportee
  • Owned by a team to which Reportee is a team member
  • Shared by a team to which Reportee is a team member

Which records are not affected by Manager Hierarchy ?

To put in simple terms, any of the records which does not meet the above four conditions is not affected by Manager Hierarchy. So the records which the reportee gains access due to his security prvileges (Business Unit/ Parent child/ organization) are not affected by this. Confused? Don’t worry. We will come back to this.

 

So let’s take these scenarios one by one.

Scenario 1:

Record owner = Reportee

User B creates a record – ‘Record for User B’. So this record is being owned by User B.  As per Manager Hierarchy, user A is able to read/ write this record since User B is direct reportee of User A. No surprises here right. After all everyone knows that.

First of all, to have write access to the reportee record, User A should be having at-least user level write privilege on the entity through his security role. Otherwise he won’t be able to write the reportee’s record even through Manager Hierarchy.

Also another point –Delete” privilege is not part of Manage security. Hence Manager won’t be able delete the reportee’s record.

 

Scenario 2:

Record shared to Reportee

Another user shares a record with User B with all the privileges – Read/ write/ append/ append to/ share. User A will now see this record because of Manager Hierarchy. However although the reportee have all the privileges on this record by virtue of sharing, through Manager Hierarchy, User A will only have read-only access to this record.

 

Scenario 3:

Record owned by a team which the reportee is member of

this behavior is same as Scenario1

 

Scenario 4:

Record Shared to a team which the reportee is member of

This behavior is same as Scenario 2

 

Now say for example User C goes ahead and creates record. Since User B and User C are both in the same business Unit (North America in example here), by virtue of their business unit read privilege on security role, User B would be able to see the record. However since User B is not the owner/ not shared to him/ not owned by the team to which he belongs/ not shared to the team to which he belongs, this record is not affected by Manager hierarchy and hence User A is not able to view this record.

 

Hope this clears out any doubt with Manager Hierarchy.

Debajit Dutta

(Dynamics MVP)

For corporate training/ consulting, please reach out to us at info@xrmforyou.com or visit our website – xrmforyou.com

Advertisements

Published at Tue, 15 May 2018 17:03:31 +0000

Leave a Reply

Your email address will not be published. Required fields are marked *