Hierarchical security in Dataverse

The standard Dataverse security model — security roles with table privileges scoped by business unit — covers most scenarios. But it doesn't naturally handle "managers should see their reports' records, recursively". Hierarchical security adds that capability through two hierarchy types — manager hierarchy and position hierarchy — that grant additional access along the chain of command.

Manager hierarchy security. Based on the manager lookup on the user record:

• User A's manager is User B; User B's manager is User C.
• With manager hierarchy security enabled:
  • User B (the manager) gets access to records owned by User A (their direct report).
  • User C (the manager of the manager) gets access to records owned by User A and User B.
• Depth parameter controls how deep — depth 1 means direct reports only; depth 2 means reports and their reports; depth N means N levels.

Position hierarchy security. Similar but based on organisational positions instead of personal manager relationships:

• The organisation has a hierarchy of positions: CEO → COO → Regional Director → Country Manager → Account Manager.
• Each position is associated with users (one or many).
• Users in higher positions get access to records owned by users in lower positions, by position lineage.

Position hierarchy is more stable than manager hierarchy — when a manager changes, position relationships often stay the same. Used in matrix organisations where personal manager isn't the operational hierarchy.

Depth and table configuration. Hierarchical security is configured:

• Enable hierarchy security at the environment level.
• Choose hierarchy type — Manager or Position (a tenant uses one or the other, not both).
• Per-table opt-in — each table can be marked as hierarchy-enabled or not. Sensitive tables can be excluded.
• Depth parameter — maximum levels of hierarchy that confer access.

Use cases.

• Sales management — district sales managers see their team's opportunities; regional managers see all districts in the region; national VP sees all regions.
• Customer service supervisors — see cases owned by agents reporting to them.
• Project portfolio review — directors see projects owned by their portfolio's project managers.
• HR escalation — HR business partners see records related to employees in their reporting structure.

Combining with business unit security. Hierarchical security adds to (not replaces) business unit security. A user might:

• Have business-unit-scoped read access to all records in their BU.
• Plus hierarchical access to records owned by their reports in any BU.

Both layer; the user's effective access is the union.

Manager vs Position — choosing.

• Manager — simpler to configure (manager lookup already populated on users); reflects the live reporting relationship.
• Position — more stable across re-orgs (positions persist while people change); supports matrix organisations.

Most enterprises use one or the other; Microsoft requires the choice.

Depth considerations.

• Depth 1 — direct reports only. The most restrictive option that still provides manager visibility.
• Depth 2 or 3 — practical for most organisations; visibility through a few levels.
• Depth unlimited — the entire downstream tree. Powerful but produces very large access sets for senior people; performance impact.

Higher depths produce slower queries — the platform must traverse the hierarchy on every access check.

Performance. Hierarchical security adds overhead — every record access checks the hierarchy. Optimisations:

• Limit hierarchical-enabled tables to those that truly need it.
• Choose moderate depth (1–3).
• Combine with business unit security for coarse filtering before hierarchy applies.

For very large enterprises (tens of thousands of users, complex hierarchies), hierarchical security can introduce noticeable latency. Test and tune.

Manager hierarchy data maintenance. The mechanism only works if the manager / position data is current. Common failures:

• Manager not set on a user record — no one above them sees their records.
• Stale manager — old reporting line; the wrong manager sees the records.
• Departing manager — records become inaccessible until the new manager is configured.

HR / IT integration should keep manager / position data current — automated synchronisation from HRIS systems is the standard pattern.

Limits.

• One hierarchy type per environment — can't use both Manager and Position simultaneously.
• Per-record overrides are not supported through hierarchy — must use record sharing for exceptions.
• Some operations still require explicit ownership transfer rather than hierarchy access (some workflow triggers, assignment).
• Hierarchical security applies to read and update privileges only — delete, create, append still controlled by security role.

Common pitfalls.

• Over-permissive depth — senior executives can see everyone's records, slowing their queries and producing irrelevant lists.
• Stale hierarchy data — security gaps when reporting changes aren't reflected.
• Performance surprises at scale — the overhead becomes meaningful with large user bases.

Operational reality. Hierarchical security is the right answer for "manager visibility" requirements. Configure deliberately; integrate hierarchy data with HRIS; audit periodically; tune depth based on actual needs.