Microsoft Dynamics 365 Customer Experience Analyst : Implement hierarchy security

Hierarchy security in Microsoft Dataverse (Dynamics 365) is a security model feature that allows organizations to manage access to records based on a hierarchical structure, such as a manager-subordinate relationship or a custom business hierarchy. Instead of granting broad security roles to provide visibility into records, hierarchy security enables users to gain access to records owned by their subordinates or by individuals lower in the hierarchy, while still respecting the organization’s existing role-based security rules. For example, a sales manager can automatically view and work with opportunities owned by their team members without requiring additional sharing or administrative overhead. This approach improves flexibility, reduces the need for complex security configurations, and ensures data access aligns naturally with organizational reporting lines and responsibilities.


What is Hierarchy Security?

Hierarchy security is an additional security model in Dataverse that lets organizations control record access based on manager-subordinate relationships or custom-defined positions in a hierarchy.

It is not a replacement for Role-Based Security (RBS) or Field-Level Security (FLS) but works on top of them to make access more natural in organizations with layered management structures.

Instead of having to share every record or assign wide roles, hierarchy security automatically allows higher-level users (like managers) to access records owned by people lower in the hierarchy (like team members).

Why It’s Needed

  • Without hierarchy security, you would have to rely on manual record sharing or broad privileges (like giving managers “organization-level” read access).
  • That approach is inefficient and can lead to too much access.
  • Hierarchy security gives a middle ground: managers see just their team’s records, not the entire organization.

 Types of Hierarchy Models

 1. Manager Hierarchy

  •  Based on the manager field in the user profile (systemuser entity).
  •  Access flows from manager → subordinate.
  •  Example:
    •  A Sales Manager (User A) is set as the manager of Sales Rep (User B).
    •  User A can automatically see records owned by User B, if permitted.
  •  Good for: organizational structures where managers need visibility into their direct reports’ work.

 2. Position Hierarchy

  • Based on a custom hierarchy of positions (e.g., Regional Manager → Branch Manager → Sales Rep).
  • A position defines a role in the org, and users are assigned to positions.
  • Higher-level positions gain access to records owned by lower-level positions.
  • Example:
    •  “Director of Sales” → “Area Sales Manager” → “Sales Representative”.
    •  Anyone in a higher position can see records owned by users in lower positions.
  •  Good for: organizations with matrix structures or non-traditional reporting lines.

How Access is Determined

  • Hierarchy security works in combination with security roles.
  • A manager/position-holder can see records owned by subordinates only if their security role allows access to that entity.
  • Example: If a manager’s security role doesn’t allow access to Opportunities, they won’t see their subordinate’s opportunities even if hierarchy security is enabled.

Key Features

  • Depth Control: You can set how many levels deep a manager can see (e.g., only direct reports, or 3 levels down).
  • Performance Safe: Limited to 50,000 subordinates per user for performance.
  • Applies only to user-owned records (not organization-owned).
  • Respects other security: Field-level and team-based security still apply.

Benefits

  • Automatic visibility: Managers don’t need manual sharing.
  • Granular access: Better than giving organization-wide privileges.
  • Flexible: Supports both traditional and custom hierarchies.
  • Security-efficient: Reduces excessive access while keeping oversight intact.

Example Scenario

Imagine an insurance company:

  • Director of Sales (top)
  • Regional Managers (middle)
  • Agents (bottom)

Agents own leads and opportunities. With hierarchy security enabled:

  • Regional Managers automatically see their agents’ records.
  • Director automatically sees all records under all Regional Managers.
  • No one outside their reporting line can see the records.

Limitations

  • Not available for organization-owned entities (like currencies, business units).
  • Large hierarchies (more than 50k users) may impact performance.
  • Doesn’t bypass other restrictions (e.g., if a role doesn’t allow Create, manager can’t create).
  • Works only with user-owned records, not team-owned unless user is part of the team.

In summary:

Hierarchy Security in Dataverse extends role-based security by letting managers or higher positions automatically see records of their subordinates, either through the Manager Hierarchy (user → manager field) or Position Hierarchy (custom org structure). It strikes a balance between strict security and flexible visibility.

Comments

Popular posts from this blog

Effective Strategies for Debugging Plugins in Dynamics CRM

Connecting the Dots: FetchXML and Web API Integration in Dataverse

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse