Salesforce Role Hierarchy Testing
Salesforce role hierarchy testing verifies the upward flow of record access: that users see records owned by, or shared with, people below them in the hierarchy, that peers in parallel branches stay isolated, and that reorganizations move visibility to the right people. SyntraFlow is designed to exercise these relationships as real personas against representative records, rather than inferring them from the role tree in Setup.
A role hierarchy is an org chart for data access, and every reorganization quietly redraws it.
Why the role hierarchy is easy to get wrong
When the org-wide default for an object is Private or Public Read Only, the role hierarchy becomes one of the main ways records are opened up. A user inherits the same access to a record as the users below them in the hierarchy — whether that access comes from ownership, a sharing rule or team membership. It is a simple principle that produces complicated outcomes once an org has hundreds of roles, several business units and a history of restructures.
Three settings change the picture further. For custom objects, the Grant Access Using Hierarchies option in Sharing Settings can be turned off, so managers no longer inherit access on that object even though they do everywhere else. For standard objects hierarchy access is always granted, but each role also carries its own case, contact and opportunity access settings for accounts owned by users in that role. And sharing rules that target Roles and Subordinates widen access down a branch, which interacts with inheritance in ways that are rarely documented.
None of these produce errors when they are misconfigured. A sales director sees a peer region's pipeline, a newly created role sits under the wrong parent, or a service manager loses sight of escalated cases after a user moves teams. The only way to know is to log in as the persona, look at real records and compare against intent. For the rule-based layer on top, see sharing rule testing.
Role hierarchy behaviors and what to validate
Each behavior needs a positive and a negative check, run with personas in the same branch and in a parallel branch.
| Behavior | What it controls | What to validate |
|---|---|---|
| Upward inheritance | Users above a role inherit access to records owned by or shared with users below. | A manager sees a direct report's records; a skip-level executive sees them too. |
| Peer isolation | Users in sibling roles do not inherit each other's records. | Two regional managers under the same director cannot see each other's team records. |
| Grant Access Using Hierarchies | Whether inheritance applies on a given custom object. | With the option off, managers see only records they own or that are shared to them directly. |
| Role-level account access | Case, contact and opportunity access for accounts owned by users in the role. | Users in the role get the configured access to child records on accounts their role owns, and no more. |
| Roles and Subordinates sharing | Sharing rules that open records to a role and everyone beneath it. | The whole intended branch gains access and roles outside it do not. |
| Users without a role | Record owners that have no role assigned. | Records owned by role-less users are visible only where intended, since no manager inherits them. |
| Portal and partner roles | External account roles beneath an internal account owner's role. | External roles see only their own account's records and never inherit internal visibility. |
Where role hierarchy defects come from
Most defects are not in the original design. They arrive with ordinary organizational change.
Reorganizations
Roles are re-parented or merged to match a new org chart, and records owned by the moved branch become visible to a different set of managers.
User moves
A user changes role, so the records they own change audience immediately, and records they could previously see through subordinates disappear from view.
Placeholder roles
Temporary or catch-all roles created for migrations or contractors sit near the top of the tree and inherit far more than anyone intended.
New custom objects
An object ships with hierarchy access enabled by default when the design called for owner-only visibility, or the reverse.
Hierarchy confusion
Teams assume the forecast or territory hierarchy governs record access when it is the role hierarchy that does, so tests target the wrong structure.
Ownership transfers
Bulk record ownership changes during a data load move large volumes of records into branches whose managers were never meant to see them.
A role hierarchy testing workflow
The workflow isolates the hierarchy as the variable, so a pass or fail is attributable to role placement rather than another access layer.
Snapshot the hierarchy
Capture the current role tree, the Grant Access Using Hierarchies setting per custom object and the role-level access settings, so tests are tied to a known version.
Pick a representative slice
Choose a branch with at least three levels and a parallel sibling branch, plus a role-less user, rather than trying to test every role in a large org.
Assign personas to roles
Place test users at each chosen level with the same profile and permission sets, so differences in visibility come only from their position.
Seed owned records
Create records owned by users at the bottom of each branch, on objects with Private defaults, so inheritance is the only path to visibility.
Assert up, across and down
Confirm managers see subordinates' records, siblings do not see each other's, and subordinates do not see their managers' records unless sharing grants it.
Rehearse a move
Change a persona's role or re-parent a role in the sandbox, allow sharing recalculation to complete, then re-run the assertions against the new expected state.
Testing reorganizations before they reach production
A restructure is the moment role hierarchy testing earns its cost. Changing the role tree in a large org triggers sharing recalculation, which can take time and can be deferred by administrators during bulk changes. Tests that run before recalculation completes produce misleading results, so scenarios should confirm recalculation has finished before asserting visibility.
The practical approach is to build the new hierarchy in a full or partial copy sandbox, load the planned user-to-role mapping, and run the same persona scenarios against both the old and new structures. The difference between the two runs is the access change the business is actually approving. Presenting it as a list of who gains and who loses visibility to which records turns an abstract org-chart discussion into something a data owner can sign off. Sandbox refresh validation and org comparison help confirm the sandbox reflects production before the rehearsal starts.
Role hierarchy scenarios worth automating
These scenarios cover the relationships that most often change and the ones that carry the most sensitive data.
- A regional sales manager sees opportunities owned by reps in the region and none owned by reps in a neighboring region.
- A vice president two levels up sees the same opportunities, confirming skip-level inheritance.
- A service team lead loses visibility of a rep's open cases the moment that rep moves to another team, after recalculation completes.
- A custom compensation object with Grant Access Using Hierarchies disabled stays owner-only, even for executives.
- Users in a role with opportunity access set to view only cannot edit opportunities on accounts owned by their role, while the opportunity owner can.
- A partner user's role under the channel manager sees only records for the partner account, never the channel manager's internal pipeline.
- Records owned by an integration user with no role remain hidden from managers unless a sharing rule deliberately opens them.
What SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against a sandbox that reflects your hierarchy.
Position-aware personas
Personas can be configured by role position — manager, peer, subordinate, role-less — so scenarios describe relationships instead of individual usernames.
Before-and-after runs
The same visibility scenarios can be run before and after a hierarchy change, producing a gains-and-losses view of record access.
Recalculation-aware timing
Scenarios can wait for sharing recalculation to settle before asserting, avoiding false results during bulk role changes.
Regression inclusion
Role hierarchy checks can be added to the security regression pack so every restructure is re-proven.
Related pages
Salesforce security testing
The parent guide to validating every Salesforce access layer.
Sharing rule testing
Tests the rule-based access that combines with hierarchy inheritance.
Restriction rule testing
Covers the filters that can narrow what a manager inherits.
Experience Cloud security testing
Validates external and partner roles in portal contexts.
Forecasting testing
Covers roll-ups that often use a separate forecast hierarchy.
Org comparison
Confirms the hierarchy in a sandbox matches production before testing.
Role Hierarchy Testing testing FAQs
What is Salesforce role hierarchy testing?
It is the validation that record access flows up the role hierarchy as designed. Tests run as personas at different positions to confirm managers inherit subordinates' record access, peers in parallel branches stay isolated and role changes move visibility to the right people. It focuses on real records rather than the role tree diagram.
What does Grant Access Using Hierarchies do?
It controls whether users higher in the role hierarchy inherit access to records on a custom object that are owned by or shared with users below them. It can be disabled for custom objects in Sharing Settings, while standard objects always grant hierarchy access. Tests should confirm the setting matches the intended visibility for each custom object.
Does the role hierarchy give access if the org-wide default is Public Read/Write?
In that case every user already has read and edit access, so the hierarchy adds little on that object. Role hierarchy testing matters most on objects set to Private or Public Read Only, where inheritance is a primary route to visibility. Checking org-wide defaults first tells you which objects need hierarchy scenarios.
How do you test a planned reorganization?
Build the new role tree and user mapping in a sandbox that mirrors production, wait for sharing recalculation, then run the same persona scenarios used against the current structure. Comparing the two runs shows exactly who gains and loses visibility, which data owners can review before the change goes live.
How is role hierarchy testing different from sharing rule testing?
Role hierarchy testing validates inheritance based on where users sit in the tree. Sharing rule testing validates owner-based and criteria-based rules that open records to groups and roles. The two interact, so a thorough suite controls one while testing the other.
Is SyntraFlow role hierarchy testing available today?
SyntraFlow's Salesforce security testing capabilities, including persona-based hierarchy scenarios, are available for demonstration and proof-of-concept validation. The personas, roles and objects are aligned to your org during that engagement.
See exactly who gains access when your hierarchy changes
Run persona-based visibility scenarios before and after a restructure and review the difference.