How to design and build a Role Hierarchy

Configuring a Role Hierarchy is an architectural exercise more than an admin task. The hierarchy you build lives for the life of the org, and changing it after thousands of records have been shared through it produces hours of recalculation and visibility gaps in the meantime. Design carefully.

1. 1
   Open Setup and navigate to Role Hierarchy

   Setup > Users > Role Hierarchy. The default tree view is easier to reason about than the flat list view.

2. 2
   Map the operational reporting structure on paper first

   Sketch out who approves whose work, with named-account books, regional structures, and any matrix relationships. Decide which goes through Role Hierarchy and which goes through Public Groups or Sharing Rules.

3. 3
   Click Add Role

   For each Role, set the Label, the Role Name, the Parent Role, and the Forecast Manager flags if applicable. The Description field is useful for documenting why this Role exists.

4. 4
   Configure Grant Access Using Hierarchies per object

   In OWD (Setup > Sharing Settings), confirm Grant Access Using Hierarchies is enabled (or disabled) for each object. Default is on.

5. 5
   Assign Roles to Users

   Setup > Users > select User > Role. Configure every active User; document any deliberately Roleless users.

6. 6
   Test with representative users from each branch

   Log in as users at different depths (or use Login As) and confirm the access they see matches the intent.

7. 7
   Plan Role-change runbooks

   Document the procedure for moving users between Roles, including communication and after-hours scheduling. Role changes are operationally expensive even when they go cleanly.