A Hierarchical Relationship in Salesforce is a special, restricted relationship type that exists only on the User object. It is essentially a self-lookup (User → User), but Salesforce gives it a distinct name because of how it’s used: to model the company’s manager-employee reporting structure.
Where you see it
The standard User.ManagerId field is a hierarchical relationship. It points from one User record to another User record (the manager). This single field is what powers:
- The
$User.Managerreference in formula fields and validation rules - “Manager” as a selectable assignee in approval processes (
UserId.Managerstep) - Reporting hierarchy data in tools like Forecasting (with “use opportunity manager hierarchy”)
- The OOTB Role Hierarchy is separate, but Manager chains are often used alongside
Why it’s its own type
You might ask: isn’t this just a User → User lookup? Functionally yes, but Salesforce treats it specially because:
- It prevents circular references. You cannot set User A’s manager to User B if B’s manager (directly or transitively) is already A. Salesforce validates the chain at save.
- It’s a system-recognized hierarchy. Approvals, formulas, and process automations have built-in operators (
$User.Manager.Field) that work because Salesforce knows this field carries the hierarchy semantic. - It can only be created on the User object. You won’t see “Hierarchical Relationship” in the field-type picker on a custom object — only Lookup, Master-Detail, etc.
Creating a custom hierarchical-style relationship
If you need a manager-style hierarchy on a different object (e.g., custom Employee__c, custom Position__c), you can’t use the Hierarchical type. Instead, build a self-lookup — a Lookup field on Employee__c pointing back to Employee__c. You’ll need to:
- Add a validation rule or trigger to prevent A pointing to B while B (directly/transitively) points to A
- Add cycle-detection logic in any Apex that traverses the chain (use a
Set<Id>of visited records to break loops) - Optionally surface the manager chain in a custom related list or component
Salesforce’s hierarchical type does all of this for free for User.
The Account Hierarchy nuance
Don’t confuse Hierarchical Relationship with Account Hierarchy, which is a separate feature: Account.ParentId is a standard self-lookup that powers the View Account Hierarchy button. It is not the same as the User Hierarchical Relationship — it’s a regular self-lookup with a built-in viewer page.
Example formula using the hierarchy
$User.Manager.EmailIn a workflow email or validation rule, this evaluates to the current running user’s manager’s email. You can also chain — $User.Manager.Manager.Email — to walk up the hierarchy.
Limits and constraints
| Concern | Detail |
|---|---|
| Available on | User object only |
| Direction | Self-relationship — User → User |
| Cycle prevention | Enforced automatically by the platform |
| Field name | ManagerId (standard); you can also add custom hierarchical fields but only on User if you have such configuration; in practice this is rarely needed |
| Reporting | Roll-up summary not available |
| Approvals | Built-in support for “Manager of the Record’s Owner” |
When this question comes up in interviews
The interviewer usually wants to know that you:
- Recognize Hierarchical Relationship is the User-specific type.
- Know the manager chain field (
User.ManagerId). - Can distinguish it from a self-lookup on a custom object.
- Understand how it integrates with approvals and
$User.Manager.*formulas.
Verified against: Salesforce Help — User Object Fields and Hierarchical Relationships. Last reviewed 2026-05-17.