Hierarchy security is a manager-based access model that sits on top of the security roles covered in the last chapter. It doesn't replace roles — it's additive: it quietly extends a manager's reach into their team's records, without touching the role assigned to anyone.
There are two flavors: Manager Hierarchy, based on the reporting line, and Position Hierarchy, based on a defined position structure. Both solve the same underlying problem in slightly different ways.
- Hierarchy security is additive — it layers on top of security roles, it doesn't replace them
- Manager Hierarchy follows the "Manager" field set on each user record
- Position Hierarchy follows a defined position structure instead of reporting lines
- Access flows to direct and indirect reports' records — read, plus limited write
Why it exists
Without hierarchy security, giving a manager visibility into their team's records means widening their security role — typically up to Business Unit or Parent: Child Business Units access level. That works, but it's a blunt instrument.
A broader role doesn't just show the manager their own team's records. It shows them everyone else's in that business unit too, whether those people report to them or not. Hierarchy security exists to close that gap: it grants exactly the reach a manager actually needs — their reporting line — without inflating their role at all.
A badge that also opens your team's lockers
Think of a manager's badge as normally opening just their own office door, same as anyone else's. Hierarchy security quietly reprograms that badge so it also opens the personal lockers of their direct reports — automatically, because of who reports to whom. No master key to the whole building required, and nobody else's locker unlocks for it.
Manager Hierarchy
This model reads straight off the Manager field already set on each user record. If Priya's manager field points to Daniel, Daniel automatically gains access to Priya's records. If Priya herself manages a team, Daniel gains access to their records too — the reach extends down through indirect reports, not just the direct ones.
Manager Hierarchy is the simplest option to turn on, because most organizations already keep the Manager field current as part of basic user setup. No extra structure needs to be built first.
Position Hierarchy
Sometimes the reporting line in the system doesn't match the access you actually want to follow — a matrixed org, a dotted-line manager, or a role that should see a team's records without literally being everyone's line manager. Position Hierarchy solves this by defining a separate position structure, independent of the Manager field, and granting access based on where a user's position sits in that structure instead.
It takes more setup than Manager Hierarchy — positions have to be defined and users assigned to them — but it decouples access from HR reporting lines entirely, which Manager Hierarchy can't do.
| Manager Hierarchy | Position Hierarchy | |
|---|---|---|
| Based on | The "Manager" field on each user record | A defined position structure, set up separately |
| Best for | Straightforward orgs where reporting lines already match who should see whose records | Matrixed orgs, dotted-line managers, or access that needs to follow a structure the reporting line doesn't reflect |
What access it actually grants
Hierarchy security is deliberately restrained. It gives a manager read access to their reports' records, plus limited write access on certain tables — enough to review, coach, and step in when needed. It doesn't hand over Delete, Assign, or Share, and it doesn't touch anyone else's role.
This chapter builds directly on the last one: security roles set the baseline for what a job function can do, and hierarchy security layers a manager's team on top of that baseline automatically. Later in this course, teams and sharing add still more ways to extend access without touching roles.