Salesforce Sharing Rule Testing
Salesforce sharing rule testing validates the record-level access model: the org-wide defaults that set the baseline, the owner-based and criteria-based sharing rules that open records to groups and roles, and the manual and Apex sharing that grants access one record at a time. SyntraFlow is designed to exercise that model with representative records and personas, so visibility is proven by behavior rather than read from Setup.
Sharing rules act on data, so a rule that was correct on the day it was built can drift as records and groups change.
Why sharing has to be tested with records
Object permissions decide whether a user can work with an object at all. Sharing decides which individual records they can reach. The two are independent, which is why a user with full read and edit permission on Opportunity can still see only a handful of opportunities, and why a user with a correct profile can still see far too many.
Org-wide defaults set the most restrictive baseline for each object, separately for internal and external users. Everything else opens access from there. Owner-based sharing rules share records owned by members of one group or role with another. Criteria-based sharing rules share records whose field values match conditions. Public group membership, account and opportunity teams, manual shares and Apex managed sharing each add further grants. The outcome for one user and one record depends on all of them at once, evaluated against the record's current owner and field values.
That dependency on data is what makes configuration review insufficient. A criteria-based rule on a Region field works perfectly until a data load introduces a new region value the rule does not mention. An owner-based rule is right until a user moves to a group that is not part of it. Testing with seeded records and real personas is the only way to see the effective result. How that result is inherited upward is covered separately in role hierarchy testing.
Sharing mechanisms and what to validate
Each mechanism grants access differently and fails differently, so each needs its own scenarios.
| Mechanism | How it grants access | What to validate |
|---|---|---|
| Org-wide defaults | Sets the baseline for internal and external users on each object. | With no other grants, personas see only records they own, or records at the level the default allows. |
| Owner-based sharing rules | Shares records owned by one group, role or territory with another. | Records owned by the source group reach the target group at the configured access level, and no one else. |
| Criteria-based sharing rules | Shares records whose field values meet conditions. | Records matching the criteria are shared, non-matching and blank-value records are not, and updates move records in and out. |
| Public groups | Collects users, roles and other groups as a sharing target. | Group membership, including nested groups, resolves to exactly the intended users. |
| Account and opportunity teams | Grants access to team members on individual records. | Team members get their configured access, which ends when they are removed from the team. |
| Manual sharing | Record owners or privileged users share a single record. | Only permitted users can share, and manual shares behave as expected when ownership changes. |
| Apex managed sharing | Code writes share records with a custom sharing reason. | Shares are created and removed by the logic that owns them, and survive or clear on ownership change as designed. |
Common sharing defects
These are the problems sharing rule tests most often uncover. None of them throws an error for the user.
Unmapped criteria values
A criteria-based rule lists specific picklist values, and a newly added value leaves its records unshared, so a team suddenly cannot see new work.
Access level too high
A rule grants Read/Write where Read Only was intended, letting a support team edit records they were only meant to reference.
Nested group sprawl
A public group contains another group that has grown over time, so a rule meant for one team now reaches several.
External default left open
The external org-wide default is wider than intended, exposing internal records to partner or customer users through a site.
Orphaned Apex shares
Custom sharing logic creates share records but never removes them, so users keep access after the business reason has ended.
Ownership change side effects
A reassignment removes manual shares and team-based access that users still depended on, and nobody notices until work stalls.
A sharing rule testing workflow
The goal is a matrix of personas against records, each with an expected access level, that can be re-run whenever the sharing model moves.
Record the sharing baseline
Capture internal and external org-wide defaults, every sharing rule with its source, target and access level, and public group membership for the objects in scope.
Define personas by group and role
Choose personas that sit inside and outside each rule's source and target groups, holding equivalent object permissions so sharing is the only variable.
Seed boundary records
Create records owned by each source group and records whose criteria fields hold matching, non-matching and blank values.
Assert access levels
For every persona and record, confirm no access, read or read and edit as expected, attempting an edit where only read is allowed.
Change the data
Update criteria fields, transfer ownership and change group membership, then confirm access follows once sharing recalculation completes.
Keep the matrix
Store the persona-by-record expectations as a reusable pack for security regression testing.
Sharing scenarios worth automating
These scenarios cover sharing behavior that changes often or protects sensitive records.
- Cases with a Region value of EMEA are shared read-only with the EMEA support group, and cases for other regions are not.
- A new Region picklist value is introduced, and the test confirms whether its cases are shared as the business now intends.
- Opportunities owned by the partner sales team are shared read and edit with channel managers, while direct sales reps see none of them.
- A user removed from a public group loses access to records shared only through that group.
- An account team member granted read-only access to opportunities can view but cannot edit them.
- A record reassigned to a new owner drops manual shares created by the previous owner, and the test confirms whether that is acceptable.
- Apex managed shares for a custom project object are removed when a user leaves the project team.
How sharing rule testing relates to its neighbors
Sharing rule testing sits in the middle of the record-access stack. Beneath it, profile permission testing and permission set testing confirm a persona can use the object at all; without that, no sharing rule can help. Above it, restriction rule testing confirms filters remove records that sharing made visible. Keeping those concerns in separate scenarios makes a failure easy to diagnose.
Sharing also has a scale dimension. Large data volumes and frequent ownership or group changes lengthen sharing recalculation, and administrators sometimes defer it during bulk operations. Test timing should respect that, and data loads in lower environments should reflect the ownership and criteria distribution of production. Sandbox seeding helps build that distribution without copying real customer records.
What SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against your sharing model.
Persona-by-record matrices
Expected access levels can be defined for each persona and seeded record, so every cell in the matrix becomes an assertion.
Data-change scenarios
Scenarios can update criteria fields, owners and group membership mid-run, then re-assert access once recalculation settles.
Read versus edit checks
Tests can attempt edits where only read access is expected, so an over-generous access level fails visibly.
Regression-ready packs
Sharing matrices can be re-run after deployments, data loads and seasonal releases to confirm record access has not moved.
Related pages
Salesforce security testing
The parent guide to validating every Salesforce access layer.
Role hierarchy testing
Validates how shared access is inherited up the role tree.
Restriction rule testing
Checks the filters applied after sharing grants access.
Negative access testing
Asserts that personas are blocked from records outside their scope.
Sandbox seeding
Builds realistic ownership and criteria data for sharing tests.
Metadata diff
Surfaces changed sharing rules before they are tested.
Sharing Rule Testing testing FAQs
What is Salesforce sharing rule testing?
It is the validation that record-level access matches intent. Tests use seeded records and personas to confirm org-wide defaults, owner-based and criteria-based sharing rules, teams, manual shares and Apex managed sharing grant exactly the intended access. Both missing access and excess access count as failures.
What is the difference between owner-based and criteria-based sharing rules?
Owner-based rules share records based on who owns them, for example records owned by one role shared with another group. Criteria-based rules share records based on field values, such as a Region or Type field. Criteria-based rules are more sensitive to data changes, so they need boundary scenarios with matching, non-matching and blank values.
Can sharing rules restrict access?
No. Sharing rules only open access beyond the org-wide default. To narrow access on records a user can already see, Salesforce provides restriction rules, which are tested separately. If a persona sees too much, the fix is usually a tighter default, a narrower rule or a restriction rule.
Why test manual and Apex managed sharing?
Both grant access record by record and are easy to lose track of. Manual shares can be removed when ownership changes, and Apex managed sharing depends on code to both create and remove share records. Tests confirm access starts and ends at the right moments.
How often should sharing tests run?
After changes to org-wide defaults, sharing rules, public groups or criteria fields, after bulk data loads or ownership transfers, and during each seasonal release preview. Including them in an automated regression pack makes that frequency practical.
Does SyntraFlow test sharing today?
Persona-based sharing scenarios are part of SyntraFlow's Salesforce security testing capabilities, available for demonstration and proof-of-concept validation. Objects, groups and personas are aligned to your org during the engagement.
Turn your sharing model into a testable matrix
See how persona-by-record scenarios can prove who reaches which records in your org.