Hierarchy Security in Dataverse

Unlocking Hierarchy Security in Dataverse.

3-minute read | Power up journey|PL-200 Study Notes

I’ve recently gained my Dataverse explorer badge from Power Up Program, and I wanted to share a specific feature that stood out to me: Hierarchy Security. It’s a documented way to solve a very common problem how to give managers visibility into their team's data without over-complicating security roles.




Here is the traceable theory I’ve gathered from Microsoft Learn.

---

 The Core Theory: Beyond Basic Roles

In Dataverse, we usually think of security in terms of Security Roles (which define what actions you can take, like Read or Delete). 

Hierarchy security is a documented additive layer that defines which records you can see based on your place in the organizational structure.

 

Verification: It does not override Roles: You still need a Security Role with "Read" access to the table.

---

 The Two Documented Models

According to Microsoft documentation, there are two distinct ways to build this hierarchy.

1. Manager Hierarchy Model






This model uses the Manager lookup field on the User record (SystemUser table).

• The Logic: Access follows the direct reporting line (Manager -> Direct Report).

• The Sync: In many organizations, this field is synced directly from Microsoft Entra ID (Office 365).

• The Boundary: By default, it respects Business Unit boundaries.

2. Position Hierarchy Model

Instead of direct reporting lines, you define "Positions" (e.g., Regional Lead) and assign users to them.





• Cross-BU Access: This model is documented to allow access across Business Units by default.

• The Structure: You define a parent position, which then grants access to the data owned by users in child positions.

---

Position Model vs. Manager Model

Feature	Manager Hierarchy	Position Hierarchy
Logic Source	Manager field on User record	Custom Position entity
HR Alignment	Must match your formal org chart	Can be completely different from HR
BU Boundary	Restricted to same/parent BU*	Bypasses Business Unit silos
Complexity	Very low (uses existing data)	Moderate (requires manual setup)

*Note: While environment settings can sometimes allow cross-BU access for managers, the Position model is the native choice for matrix structures.




The "Read-Only" Rule (Asymmetric Access)

One of the most important technical nuances I learned is that access is not the same at every level.

Depth Settings: You can configure the "Depth" (how many levels down the access extends).

• Access levels change as you go deeper into the hierarchy.
• Direct Reports (Level 1): Manager gets Read & Write access.
• Indirect Reports (Level 2+): Manager gets Read-only access.

* Microsoft recommends a depth of 3 or 4 to maintain system performance.

---

How to Set It Up (Traceable Path)

To configure this, you use the Power Platform Admin Center (PPAC):

1. Navigate to Environments > [Your Environment] > Settings.

2. Expand Users + permissions > Hierarchy security.

3. Toggle "On" and select either Manager or Position.     

   
   
   
   
   
   
   
   
   

4. Exclude Tables: Use this section to select specific tables that should not follow the hierarchy rules (useful for protecting sensitive data).

                                                        

---

Refining the Model

Set the Depth: Define how many levels deep a manager can see.
Example: A depth of 3 allows a manager to see their direct reports (Read/Write) and two levels of reports below them (Read-only).

Why? This is critical for protecting sensitive data like salaries, medical records, or private HR notes that shouldn't "roll up" to a manager.

 
For those managing large teams: Would you stick to the standard Manager Hierarchy, or have you found that the Position Model offers more flexibility for cross-department collaboration?"

📚 Verified Sources

• Microsoft Learn: Hierarchy security to control access

• Security concepts in Microsoft Dataverse