Salesforce Restriction Rule Testing
Salesforce restriction rule testing confirms that each restriction rule filters records exactly as designed — removing rows a user could otherwise see through org-wide defaults, sharing and the role hierarchy, while leaving every record they legitimately need in place. SyntraFlow is designed to exercise those rules as real personas against representative records, across every surface where a rule is enforced.
Restriction rules only take access away, so the failure you are testing for is usually a record that disappeared or one that did not.
Why restriction rules need their own tests
Most Salesforce access features add visibility. Org-wide defaults set the floor, then ownership, the role hierarchy, sharing rules, manual shares and team membership open records up. Restriction rules work in the opposite direction: they apply after all of that and filter the set of records a user already has access to, so that only records matching the rule's record criteria remain visible to users who match its user criteria.
That reversal is what makes them risky. A rule written against the wrong field, a user criterion that matches too broadly, or a picklist value that was renamed after the rule was created does not raise an error. It simply shrinks what users see. Service agents lose cases from a region they still support, or a confidential record category stays visible because the filter no longer matches the value the data actually carries. Because the result is an absence, nobody notices until a user reports that a record is missing — or an auditor finds one that should have been.
Restriction rules also sit alongside scoping rules, which look similar in Setup but do something different. A scoping rule sets which records a user sees by default in list views, lookups and reports, but it does not stop the user reaching other records they have access to. Confusing the two is a common design error, and a test suite is the most reliable place to catch it. For the broader access model these rules sit on top of, see sharing rule testing and role hierarchy testing.
Failure modes restriction rule tests catch
Each of these defects looks like correct behavior from inside a single user session. They only show up when an expected record set is compared against what a persona actually sees.
Over-filtering
The record criteria are narrower than intended, so users lose records they need for daily work, and the gap is reported as missing data rather than an access defect.
Under-filtering
The rule matches fewer records than intended — often after a picklist or record type change — so restricted records remain visible to users the rule was meant to limit.
Wrong user criteria
The user criteria reference a field such as department or a custom user attribute that is blank or inconsistently populated, so the rule applies to the wrong population.
Scoping rule used in place of a restriction
A scoping rule changes default views but leaves records reachable through search, direct URL or API, giving the appearance of restriction without the enforcement.
Rule inactive or superseded
A rule was deactivated during troubleshooting, or another active rule on the same object was added, and the effective filter is no longer what the design document describes.
Surface inconsistency
Visibility is correct in a list view but a report, a related list, global search or a SOQL query from an integration returns a different set than the design expects.
How to test a restriction rule
A restriction rule test is a comparison between an expected record set and an observed one, for a persona that matches the rule and a persona that does not.
Document the intent
Record the object, the user criteria, the record criteria and the business reason in plain language, so every assertion traces back to a stated requirement rather than to the current configuration.
Seed boundary records
Create records that match the record criteria, records that do not, and records with blank or edge values in the filter field, all shared to the test personas through ordinary sharing so the rule is the only variable.
Select matching and non-matching personas
Use at least one user who satisfies the user criteria and one who does not but has the same underlying sharing, so the effect of the rule is isolated.
Assert across surfaces
For each persona, compare expected and actual records in list views, related lists, lookups, reports, global search and API queries, since each surface must reflect the rule.
Probe direct access
Attempt to open a filtered record by its ID as the restricted persona and confirm access is denied, which distinguishes a true restriction from a default-view scoping effect.
Capture the evidence
Store persona, record, surface, expected result and actual result together, so the run can be shown to a reviewer and re-executed after the next change.
Restriction rule scenarios and what they prove
Scenarios are written against the intent of the rule, not its configuration, so they stay valid when the rule is rebuilt.
| Scenario | What it proves |
|---|---|
| A regional support agent views all cases in a shared queue list view | Only cases matching the agent's region remain visible, even though the queue grants access to all of them. |
| The same agent opens an out-of-region case by record ID | Access is denied at record level, confirming enforcement rather than a default-view filter. |
| A manager above the agent in the role hierarchy runs the case report | The manager's result set reflects whether the manager is inside or outside the rule's user criteria, not simply hierarchy inheritance. |
| Tasks and events tied to confidential records are searched globally | Activities excluded by the rule do not appear in search results or activity timelines for restricted users. |
| An integration query retrieves records via the API | The integration user either matches the rule as designed or is deliberately excluded, and the returned count matches that decision. |
| A record's filter field is updated so it moves into the restricted category | Visibility changes immediately for restricted personas without any sharing recalculation step. |
| A user's department attribute is changed | The user moves in or out of the rule's population as expected, proving the user criteria rely on a maintained field. |
Design checks to run before writing assertions
Several restriction rule problems are visible before any persona logs in. These checks shape which scenarios matter most.
- Confirm the object supports restriction rules and note how many active rules it already has, since the number of active rules per object is limited and varies by edition.
- Check that the record criteria reference stable values, and flag any picklist values or record types that release plans intend to rename.
- Verify that the user criteria field is populated for every active user in scope, including integration and automated process users.
- Identify users holding broad permissions such as View All Data or object-level View All, and decide explicitly how the rule should treat them, then test that decision.
- Distinguish every scoping rule on the object from the restriction rules, and document which requirement each one serves.
- Record which Experience Cloud or external users share the object, and hand those contexts to Experience Cloud security testing.
Where restriction rules meet the rest of the access model
A restriction rule cannot grant access, so every restriction rule test depends on the layers underneath it being right. If a persona cannot see a record, the cause might be the rule — or it might be an org-wide default, a missing sharing rule or a profile without read access on the object. Good tests separate those causes by controlling the sharing baseline and asserting that the persona would see the record with the rule inactive, which is practical in a sandbox and makes the rule's effect unambiguous.
The deny side of this work overlaps with negative access testing, which asserts that personas are blocked from records and fields generally. Restriction rule testing is narrower: it proves one filtering mechanism on specific objects, including the cases where the rule must not remove a record. Both belong in the same security regression pack so a later change to a picklist or a user attribute cannot quietly alter who sees what.
What SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against a sandbox that mirrors your restriction rule design.
Persona-based execution
Scenarios can be configured to run as named test personas that match or miss a rule's user criteria, so visibility is observed from the user's side.
Expected record sets
Each scenario can hold an explicit list of records that must be visible and records that must not, making both over- and under-filtering fail the test.
Multi-surface assertions
The same expectation can be checked across list views, reports, search and API queries, exposing a surface that behaves differently.
Change-triggered re-runs
Restriction rule scenarios can be included in a regression pack that re-runs after metadata deployments and seasonal releases.
Related pages
Salesforce security testing
The parent guide to validating every layer of Salesforce access.
Sharing rule testing
Tests the access that restriction rules later filter.
Negative access testing
Asserts the deny cases across objects, fields and records.
Security regression testing
Keeps restriction rule scenarios running after every change.
Configuration drift
Spots rules that differ between sandbox and production.
Synthetic test data
Builds the boundary records restriction rule tests depend on.
Restriction Rule Testing testing FAQs
What is Salesforce restriction rule testing?
It is the practice of proving that a restriction rule removes exactly the intended records from view for the intended users. Tests compare an expected record set with what matching and non-matching personas actually see across list views, reports, search and API queries. Both hidden records that should be visible and visible records that should be hidden count as failures.
How is a restriction rule different from a scoping rule?
A restriction rule filters the records a user has access to, so records outside its criteria cannot be reached. A scoping rule only changes which records a user sees by default, and the user can still reach other accessible records. Testing direct access to a record by ID is the simplest way to tell which behavior is in effect.
Can a restriction rule give a user access to a record?
No. Restriction rules only narrow access that has already been granted through org-wide defaults, ownership, the role hierarchy or sharing. If a persona cannot see a record that the rule should allow, the cause is in one of those underlying layers, which is why tests control the sharing baseline first.
Which surfaces should restriction rule tests cover?
At minimum list views, related lists, lookups, reports, global search and API queries used by integrations. A rule that looks correct in one list view can still be judged against expectations in a report or search result, so assertions should span the surfaces your users and integrations actually rely on.
When should restriction rule tests be re-run?
After any change to the rule itself, to the fields its criteria reference, to picklist values or record types on the object, and to the user attributes in its user criteria. They also belong in the regression pack run during each seasonal release preview window.
Does SyntraFlow replace Salesforce security tooling for restriction rules?
No. SyntraFlow is designed to verify how configured rules behave for real personas and records. It complements Salesforce Shield, Security Center and code scanning rather than replacing them, and its capabilities are available for demonstration and proof-of-concept validation.
Prove your restriction rules filter the right records
See how persona-based scenarios can compare expected and actual visibility across every surface in your org.