What it does

Hierarchy security gives managers access to their reports' records without widening security roles or inventing business units. Two models are available: manager hierarchy, driven by the Manager field on the user record, and position hierarchy, driven by a separate tree of job positions that users are tagged against. Only one model can be active in an environment at a time.

Key facts

• Direct reports (or the position immediately below) give the manager Read, Write, Append and AppendTo. Anyone deeper in the chain gives Read only.
• The Depth setting controls how many levels down the read-only access reaches. Beyond that depth, nothing.
• The manager still needs at least User-level Read on the table in their security role. Hierarchy security extends reach; it does not create a privilege from nothing.
• Manager hierarchy requires the manager to be in the same business unit as the report, or a parent of it, by default. That behaviour is governed by the ManagersMustBeInSameOrParentBusinessUnitAsReports organisation setting, default true.
• Position hierarchy has no such business unit constraint, which is why it's the answer when managers span business units. A user holds one position; a position can hold many users.
• All system tables are in scope by default. Hierarchy Table Management lets you uncheck tables you don't want included.
• Microsoft's performance guidance is to keep the effective number of users under a single manager or position at 50 or fewer, using Depth to hold it down. The overall hierarchy can be larger.
• Configuration lives in the Power Platform admin centre under the environment's Settings, Users + permissions, Hierarchy security. It needs the Change Hierarchy Security Settings privilege.
• If a report has broader access than their manager — say business-unit-level read while the manager only has user-level — the manager will not see everything the report can see. Hierarchy security doesn't paper over that.
• For environments enabled after 31 January 2024, managers see records of disabled direct reports by default. Changing it means editing the AuthorizationEnableHSMForDisabledUsers organisation setting with the OrganizationSettingsEditor tool and then disabling and re-enabling hierarchy modelling.

When to use / skip

Use it when the requirement is "managers should see their team's pipeline" and nothing more exotic. It is dramatically cheaper than building a business unit per team, and it tracks the org chart automatically as long as the Manager field is maintained.

Skip it when the client's real requirement is reporting rather than record access — a manager who needs numbers, not edit rights, is often better served by a dashboard built on Organization-level read for a narrow reporting role. Skip it too when the hierarchy is wide and flat: a sales director with 300 direct reports will hurt, and the fix is Depth plus fewer tables, not more hardware.

Position hierarchy is the minority case. Reach for it only when managers genuinely need to cross business units, or when the reporting line in the system is not the access line the business wants.

Configuration decisions

• Manager hierarchy or position hierarchy. Only one can be enabled, and swapping later means re-tagging users.
• The Depth value — the trade-off is how far up the chain visibility reaches versus recalculation cost.
• Which tables stay in Hierarchy Table Management. Trim aggressively; most clients only need it on Account, Contact, Lead, Opportunity and Activity.
• Whether managers must stay inside the same or parent business unit, and therefore whether the organisation setting needs changing.
• How the Manager field gets populated and kept current — HR feed, Entra ID sync, or manual admin work. Manual maintenance is where this feature quietly dies.
• Whether disabled users' records should remain visible to their former manager after a leaver process.

Gotchas

• Enabling or disabling hierarchy modelling triggers a full recomputation across every included table. On a large environment this can time out; the mitigation is to cut the table list back and try again.
• It is not a substitute for a role. If the manager's role has no Read on Opportunity at all, they see nothing regardless of the hierarchy.
• Records shared with a report only pass read-only access up the chain, even to a direct manager.
• The Manager field is invisible on most user forms in day-to-day admin, so it goes stale. A leaver whose reports keep pointing at them is the classic cause of "why can this person still see the pipeline".
• The 50-user effective guidance is guidance, not an enforced limit — you will not get a warning, you will get slow views.
• Position hierarchy needs the Assign position for a user privilege to tag users, which System Customizer does not have by default.

Consultant notes

• Draw the client's actual org chart on a whiteboard before choosing a model. Half the time the "hierarchy" they describe is a matrix, and neither model fits cleanly.
• Demo it with three real accounts — seller, their manager, their manager's manager — and let the client see the read-only boundary for themselves. It settles arguments faster than a diagram.
• Make maintaining the Manager field an explicit line in the joiners/movers/leavers process and get someone to own it. Without that, the security model degrades within a year.
• Before go-live, check view performance for the widest manager in the business, not an average one.
• If the client is heading toward twenty business units to solve manager visibility, this is the feature to put in front of them instead.

---

Worth another look if the client restructures sales, or if manager views start feeling slow.