In large organizations using Microsoft Dynamics 365 Customer Engagement (CE), it’s common to implement role-based visibility so that users only see records relevant to their position in the hierarchy. In this article, we’ll explore how to implement hierarchical security using a real-world scenario, the methods available, pros and cons, and platform limitations.

🔍 Scenario: Multi-Level User Access

Imagine a sales organization with the following user levels:

• Sam (Level 1 – Regional Sales Director): Should see records of Level 1, 2, 3, and 4
• Alex (Level 2 – Area Manager): Should see records of Level 2, 3, and 4
• Rita (Level 3 – Branch Manager): Should see records of Level 3 and 4
• John (Level 4 – Sales Executive): Should only see their own records

The business need here is for managers to have visibility into the records of their subordinates, while subordinates only see their own data. Let’s see how this can be achieved.

🔧 Methods to Implement Hierarchy Security in Dynamics 365 CE

1. Manager-Based Hierarchical Security

This approach uses the “Manager” field on the user record in Dynamics 365. Once the reporting hierarchy is set up, managers can automatically access subordinate users’ records.

• ✅ Easy to configure using the Manager field
• ✅ Works with Owner-based access
• ✅ Automatically supports multi-level hierarchy

Steps:

1. Assign managers to users via the “Manager” lookup field on each user record.
2. Enable “Manager Hierarchy Security” in Security Settings.
3. Define depth level (e.g., 1, 2, 3 levels down).
4. Grant read access to managers based on subordinate ownership.

Limitations:

• ⚠️ Only supports read access to subordinate records
• ⚠️ Cannot apply granular field-level or business unit-based permissions
• ⚠️ Maximum depth: 5 levels

2. Position-Based Hierarchy Security (Custom or via Field Security)

This involves creating a custom “Position” hierarchy (e.g., Region > Area > Branch > Executive) and applying it manually using teams, business units, or custom logic in workflows/plugins.

Options:

• Assign users to Business Units representing organizational levels
• Create Teams and share records accordingly
• Use a plugin or Power Automate to auto-share records upward in hierarchy

Pros:

• ✅ Full flexibility over depth, access level (Read, Write, Append)
• ✅ Can use custom fields and conditions to decide sharing

Cons:

• ⚠️ More complex to manage and scale
• ⚠️ Requires automation or plugin development

3. Team-Based Sharing

Users are grouped into Teams and records are shared with teams manually or via automation.

Pros:

• ✅ Clear control over who sees what
• ✅ Easy to manage exceptions

Cons:

• ⚠️ Not hierarchical — teams need manual sharing or logic
• ⚠️ Can get messy if not well-governed

🏁 Recommended Approach for This Use Case

For this 4-level hierarchy, the best approach is to use:

• Manager Hierarchy Security – for easy upward visibility
• Field Security/Profile-level RBAC – for access control
• Supplement with Power Automate or Plugins – to share or restrict as needed

📉 Limitations of Hierarchy Security in D365 CE

• ⚠️ Manager security only applies to record ownership (not shared or team-owned records)
• ⚠️ Not suitable for matrix reporting structures
• ⚠️ Can’t restrict update/delete rights – only provides read visibility
• ⚠️ Field-level security must still be managed separately

✅ Summary

Microsoft Dynamics 365 CE provides powerful options for implementing hierarchy-based record access. In our example, Sam (Level 1) can easily be set up to view all data using Manager Hierarchy Security, while users like John (Level 4) are restricted to their own records. For more complex logic or cross-functional teams, combining manager hierarchy with team-based sharing and automation is the way forward.

Need help setting this up in your environment? Reach out to our Dynamics 365 Champions!