Hierarchy security

What it does

Hierarchy security layers management-chain access on top of the existing model. Two flavours: manager hierarchy, driven by the Manager lookup on the user row, and position hierarchy, driven by a separate tree of positions you define and tag users with. It's off by default.

Key facts

Manager hierarchy requires the manager to be in the same business unit as the report, or the parent business unit — unless record ownership across business units is on and you set ManagersMustBeInSameOrParentBusinessUnitAsReports to false.
Position hierarchy crosses business units by design. Users are tagged with one position each; a position can hold many users. Access flows down the direct ancestor path only, so a sales manager sees sales data but not support data.
A direct manager (or direct higher position) gets Read, Write, Append and AppendTo on the report's data. Non-direct ancestors in the same chain get read-only.
The manager still needs at least User-level Read on the table in their own security role. No role privilege, no hierarchy access, regardless of the hierarchy.
Depth limits how many levels down read-only access reaches. Depth 2 from the CEO reaches the VPs and the managers below them, but not their staff.
All system tables are enabled for hierarchy security by default. You exclude tables by clearing checkboxes in Hierarchy Table Management.
Changing hierarchy settings needs the Change Hierarchy Security Settings privilege. Assigning a user to a position needs Assign position for a user.
If a report has deeper access than their manager, the manager doesn't inherit it. A manager with User-level Read doesn't see everything a report with Business Unit-level Read can see.
Managers see disabled direct reports' rows in environments where hierarchy security was enabled after 31 January 2024. Older environments don't, and AuthorizationEnableHSMForDisabledUsers flips it either way — followed by disabling and re-enabling the hierarchy model.
Microsoft's performance guidance is to keep the effective hierarchy to 50 users or fewer under any one manager or position, using Depth to get there.

When to use / skip

Hierarchy security is usually the right answer when someone asks for a business unit tree. Microsoft says so explicitly: fewer business units plus hierarchy security costs far less to maintain than a large business unit hierarchy. Pick manager hierarchy when the requirement genuinely is "my manager can see my work" and the business unit constraint doesn't bite — financial services often prefer it precisely because it won't cross business units. Pick position hierarchy when access needs to follow a functional structure that doesn't match the reporting line, or when it must cross business units. Skip both if the real requirement is a fixed team seeing a fixed set of rows; that's a team, and it's simpler.

Configuration decisions

Manager versus position hierarchy, decided on whether access should be able to cross business units.
Depth, which is both a security setting and the main performance lever.
Which tables participate. Everything is on by default and most environments don't need everything.
Whether disabled users' rows stay visible to their former manager.
Who maintains the Manager lookup or the position tree, and whether it's fed from HR or kept by hand.

Gotchas

The 50-user guidance is real. Wide spans under one manager make every access check on that manager's queries more expensive, and it shows up as general sluggishness rather than an error.
Disabling and re-enabling the hierarchy model triggers a recomputation of manager record access, which takes time and can time out. The documented fix is to trim the table list and retry.
Nobody maintains the Manager field. It's blank or stale on half the user rows in most environments, and hierarchy security silently does nothing for those people.
Manager hierarchy access flows to rows shared with a report, not just rows they own — but a read-only share from outside the chain gives the manager read-only too. That subtlety confuses investigations.
A manager without the underlying table privilege gets nothing. People enable hierarchy security, test with an admin account, and conclude it works.
The Who has access view deliberately omits hierarchy-derived managers because the list can be long. So the tool you'd use to explain access doesn't show this route.

Consultant notes

Offer hierarchy security every time a client sketches a business unit tree on a whiteboard. It's usually what they actually want and it's an order of magnitude less maintenance.
Insist the Manager field is populated from the HR feed before you enable anything. Hierarchy security built on hand-maintained manager data fails quietly and intermittently, which is the worst failure mode.
Set Depth deliberately and document why. Left at a high value on a wide organisation it's the performance problem you'll be called back about.
Warn that hierarchy access is additive like everything else — it can only widen access, never restrict it. Clients sometimes expect it to constrain managers, and it does the opposite.

Revisit if the business unit restriction on manager hierarchy is relaxed further, or if the 50-user performance guidance changes.