Salesforce role hierarchy and sharing rules both affect record-level access, but they work through different relationships. The role hierarchy can open records upward through a reporting structure; sharing rules extend access to selected groups, roles, or territories. Both generally grant access beyond organization-wide defaults rather than remove permissions.

Role hierarchy follows reporting structure
The role hierarchy can grant users higher in the hierarchy access to records owned by users below them, subject to object settings and Salesforce configuration. It supports managerial visibility where records should be visible along a business reporting path.
It is not a substitute for object permissions. A user still needs the appropriate object-level access and field permissions to use the record as intended. Some objects can be configured not to grant access through hierarchy, so verify the object’s behavior.
- Map roles to actual record visibility needs, not job titles alone.
- Check organization-wide defaults and hierarchy settings.
- Test with users at different levels of the structure.
Sharing rules extend access across groups
Sharing rules can grant record access based on record ownership or criteria, sharing records with roles, groups, or other supported audiences. They are useful when teams need cross-functional visibility that does not follow the manager chain.
A sharing rule does not make a record private from someone who already has broader access, and it does not grant the object permission itself. Review criteria carefully: a rule based on a broad field can expose more records than intended.
- Use owner-based rules for predictable ownership groups.
- Use criteria-based rules only with stable, well-governed fields.
- Document the audience and access level granted.
Design the access model as a whole
Start with the organization-wide default, object permissions, role structure, teams, and required exceptions. Then add only the sharing mechanisms that fill a defined gap. Use a test matrix to verify who can see and edit representative records.
When troubleshooting unexpected access, inspect permission sets, ownership, teams, hierarchy, sharing rules, and manual sharing together. A single sharing rule rarely explains the entire effective access result.
A manager who needs visibility into a team’s owned records is a hierarchy use case. A support group that needs read access to a defined set of sales records is more likely a sharing-rule use case. In both cases, verify that object-level permissions permit the intended work.
How did this article land?
Choose one reaction. You can change it anytime.
