Configuring Roles is one of the more architecturally important Salesforce setup tasks. The Role design lives for the life of the org, and changing it after thousands of records have been created and shared through it is significantly more expensive than designing it correctly on day one.
- Open Setup and navigate to Roles
Setup > Users > Role Hierarchy. The default view shows the hierarchy as a tree, which is easier to reason about than the flat list view.
- Plan the hierarchy on paper first
Map your sales and service organization's reporting structure, including any matrix-reporting cases. Decide which relationships go through Role Hierarchy and which go through Public Groups or Sharing Rules. Keep the depth shallow (3 to 5 levels in most orgs).
- Click Add Role
For each new Role, set the Label, the Role Name (API), the Parent Role (the Role this one reports to), and the Forecast Manager-related fields if applicable.
- Configure Role-Hierarchy access per object
In OWD (Setup > Sharing Settings), confirm Grant Access Using Hierarchies is enabled (or disabled) for each object based on your sharing model.
- Assign Roles to Users
Setup > Users > select User > Role. Configure the Role for every active User; document any deliberately Roleless users.
- Test with a representative user
After assignment, log in as the user (or use Login As) and confirm they see the records they should and do not see records they should not.
- Audit assignments quarterly
Build a report grouping Users by Role and have managers confirm the assignments are correct. Role drift is one of the harder-to-catch CRM hygiene problems because it does not produce error messages.
Configure per object through OWD. Default is on for standard objects; some service-and-compliance scenarios need it off.
Mirrors Role Hierarchy by default. Customize separately only if your forecast structure differs from your operational reporting structure.
- Role Hierarchy is a sharing mechanism, not an authorization mechanism. Changes to a User's Role re-cascade sharing across every record they own; plan changes carefully.
- The Grant Access Using Hierarchies toggle in OWD lets you disable role-based propagation per object. Default is on; some objects need flat sharing.
- A User without a Role has no Role-Hierarchy-based visibility. Owned records remain visible; nothing else propagates up.
- Role design is hard to change after the fact. Once thousands of records have been shared through the hierarchy, restructuring the tree means re-running the sharing cascade across every affected record, which can take hours and produce visibility gaps in the meantime.