Hierarchy security solves a specific problem business units can’t: letting a manager see their direct and indirect reports’ records, even when that manager’s own role only grants User-level access and the reports sit in the same business unit as peers who shouldn’t see each other’s data.

Manager hierarchy

Based on the “Manager” field on the User record. A user automatically gains read (and, depending on configuration, write) access to records owned by anyone below them in that manager chain, without needing Business Unit or Organization-level role access. This mirrors a real org chart without requiring a complex business unit structure just to express “my manager can see my records.”

Position hierarchy

An alternative, more explicit structure using dedicated Position records, independent of the “Manager” field on Users. Useful when the actual reporting line for security purposes doesn’t cleanly match who HR lists as someone’s manager — for example, a matrix organization or a position that outlives whoever currently holds it.

Why this is a cheaper alternative to over-building business units. A frequent anti-pattern is creating many business units just so managers can see their team’s records. Hierarchy security often solves the same requirement without touching the BU structure at all — fewer moving parts, easier to maintain as the org chart changes, and no risk of disrupting record ownership across BUs.

Depth and scope

Hierarchy security has a configurable depth (how many levels down the chain access extends) and can be scoped per table — not every table needs to respect the management hierarchy, so it’s enabled selectively rather than globally.