Hierarchical Security Model: Manager and Position Hierarchies in Microsoft Dataverse

The hierarchical security model extends the existing security framework of Microsoft Dataverse—business units, security roles, sharing, and teams—by adding a finer‑grained access layer that can be used together with other models, reducing maintenance costs.

Two hierarchy types are supported: the manager hierarchy, which requires a manager and their report to belong to the same business unit or a parent unit, and the position hierarchy, which allows cross‑business‑unit access based on defined positions.

Note: Additional access can be granted through other security mechanisms such as security roles.

The manager hierarchy is built on the manager field of the system user table. Managers can read, write, append, and append‑to records of their direct reports, while indirect reports are read‑only; the depth setting limits how many levels of indirect reports are visible in read‑only mode. For example, a CEO can update data of sales and service VPs but only read data of sales and service managers.

An illustrative scenario with three users (User 1, User 2, User 3) shows that a manager may not see all records if a direct report has broader business‑unit read permissions.

The position hierarchy does not rely on reporting lines. Users are assigned to positions; higher positions can access data of lower positions within the same ancestor path. Direct ancestors have full read/write/append rights, while non‑direct ancestors have read‑only rights. Depth works similarly to the manager hierarchy.

Note: Users in higher positions can also see records owned by lower‑position users or their teams, as well as records directly shared with them.

To enable hierarchical security, a system administrator must update the setting: Settings → Users + Permissions → Hierarchical Security, then choose either the manager or position model. The "Change Hierarchical Security Settings" permission is required.

Important: You must have the "Change Hierarchical Security Settings" permission to modify this configuration.

All system tables have hierarchical security enabled by default; specific tables can be excluded in the "Hierarchical Table Management" area. The depth value controls how many levels of read‑only access a manager or position receives. For example, a depth of 2 lets a manager see their own accounts and those of reports up to two levels deep.

Important: This is a preview feature and is not intended for production use.

Managers and positions are set up via the system user record: the manager field (ParentsystemuserID) defines the manager hierarchy, while the Position lookup assigns users to positions. Adding or changing a user's position requires the "Assign Position to User" permission.

To create a position hierarchy, go to Settings → Users + Permissions → Positions, define each position’s name, parent, and description, and add users via the "Users in this Position" lookup. The resulting hierarchy is visualised in the following diagram.

Including or excluding records of disabled users requires the OrganizationSettingsEditor tool: set AuthorizationEnableHSMForDisabledUsers to true (include) or false (exclude), then disable and re‑enable hierarchical modeling to apply the change.

Note: Re‑enabling may take time as the system recomputes access rights; reduce the number of tables in the hierarchical table list if timeouts occur.

Performance recommendations advise keeping the effective hierarchy under 50 users per manager or position, using the depth setting to limit read‑only levels, and combining hierarchical security with other models instead of creating many business units.

See also

Security in Microsoft Dataverse

Query and visualize hierarchical data