Short answer: a scoping rule changes what a user sees by default without changing what they are allowed to see. It narrows the working set, not the permission. Restriction rules do the opposite: they remove access entirely, and a user cannot get back to a restricted record by any route. Confusing the two is how a focus feature ends up on a security design document.
What a scoping rule does
You define which users the rule applies to, and a filter on the object. Those users then get the filtered set as their default view of that object. A sales rep in the Northern region opens Accounts and sees Northern accounts, because that is what the rule scoped them to, even though their sharing access covers the whole country.
The access is untouched. If the same rep is sent a link to a Southern account, it opens. If they search for it by name, it appears. If a colleague shares a report, the rows are there. The rule shaped the default, and the default was never a wall.
Why that is useful anyway
Most complaints about “too much data” are not security complaints. They are usability complaints. A rep with 40,000 accounts in scope does not have a confidentiality problem, they have a list view problem, and the usual fix is a pile of personal list views that nobody maintains and that report filters then contradict.
Scoping rules move that filtering from every individual list view to one piece of declarative metadata. The maintenance cost drops and the behaviour becomes consistent across the users you scoped. That is the entire value proposition and it is a reasonable one.
The difference from restriction rules, stated plainly
- Scoping rule: changes the default record set. Access is unchanged. A determined user reaches everything they could reach before.
- Restriction rule: removes records from every surface, including SOQL and the API. There is no route back to a restricted record.
- Object coverage differs. Scoping rules cover the major standard objects that restriction rules do not, which is exactly why people reach for scoping rules and then misdescribe them.
- Auditability differs. A scoping rule proves nothing to an auditor. A restriction rule is evidence of a control.
If a compliance requirement says a group must not be able to see certain records, a scoping rule does not meet it. Write that down somewhere the next person will find it.
Setting one up
Scoping rules live in Setup under the object, defined with user criteria and record criteria in the same shape as restriction rules. They deploy as metadata, so they belong in source control. Activation is a separate step from creation, which is helpful: you can build the rule, review the filter, and switch it on in a controlled release.
Test the filter against a real user before activating. A criteria field that is blank on half your records quietly hides half your records, and users will report it as a list view bug.
Things that surprise people
Not every surface respects the scope in the way a user expects. Global search, direct record links, related lists on a parent record and reports each have their own behaviour, and the safe assumption is that anything which is not the object’s default list view may show out-of-scope records. Verify the ones your users actually use rather than reasoning from the documentation.
Scoping also interacts badly with training. A user told “you only see your region” who then stumbles on a record from elsewhere will file a security ticket. Describe the feature as a filter.
Using both together
They are not mutually exclusive. On a custom object you might restrict a contractor population from a sensitive subset, then scope the remaining internal users to their business unit for convenience. One rule is the control, the other is the ergonomics. Keep the two purposes separate in your documentation, because they will be reviewed by different people for different reasons.
Frequently asked
Can users turn the scope off themselves? They cannot change the rule, but they can see out-of-scope records through search and direct links. The scope is a default, not a toggle they are locked into.
Do scoping rules improve performance? Sometimes, because the default queries return fewer rows. Do not count on it as a performance strategy on a skewed object.
Do they apply to the API? Treat API access as unscoped for design purposes. An integration user reading through the API is not the scenario scoping rules were built for.
Which should I pick for a compliance requirement? Restriction rules, if the object is supported. If it is not, the answer is org-wide defaults and a sharing redesign, not scoping.
