Перейти до вмісту

Restriction and Scoping Rules

Цей контент ще не доступний вашою мовою.

Module 7 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Every way so far opens records. What do you do when you need to close some again, for some users?

Sets 1 to 5 open the file cabinets. Set 6 is the only set that closes them again. Two ways, and they’re very different: restriction rules are strict, and scoping rules are soft.

Remember from module 2: it’s easier to open up later than to lock down later. Set 6 is how Salesforce lets you lock down later, on a few objects, with a few rules. It’s powerful, and it has limits you need to know before you lean on it.

Set 6, taking access away Set 6, taking access away: two ways. 18 Restriction rules, strict and always on: users see only the records that match, everywhere; for custom and external objects, contracts, tasks, events and a few more; two active per object, five on Performance and Unlimited editions. 19 Scoping rules, soft, and the user can switch them off: they filter list views, reports and SOQL; they filter, they don't secure; for accounts, cases, contacts and more. Footnote: only one restriction or scoping rule should apply to a user on each object. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.56.0", "built": "2026-10-30", "id": "DGM-SVA-WS-13", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} 18 Restriction rules strict: always on Only records that match, everywhere Custom objects, contracts, tasks, events and more 2 active per object, 5 on some editions 19 Scoping rules soft: the user can switch List views, reports and SOQL Filters, doesn't secure Accounts, cases, contacts and more Only one restriction or scoping rule should apply to a user on each object. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

A restriction rule is a second-level filter. It sits on top of all the sharing you’ve set up, and kicks in after it. Salesforce: “Restriction rules filter the records that a user has access to so that they can access only the records that match the criteria you specify” (Restriction Rules (opens in a new tab), Salesforce Help, checked 2026-11-01).

Every rule has two filters: one on the user, one on the record. The user filter decides who the rule applies to, from a field on the user or a permission. The record filter decides what they can still see. That’s the real power: you can use things about the user that sharing never could.

Here’s my demo. I have an airport object with every airport in the world: small, large, heliports, closed. I add a checkbox on the user, “small airport only,” and a restriction rule: if the user’s box is checked, they see only airports whose type is small. I check the box on Paul the pilot. Now Paul, in his own browser, sorts the airports, and every one is small. Whatever else shares airports with him, the restriction rule kicks in at the end and narrows it.

It applies everywhere: “Links, List Views, Lookups, Records, Related Lists, Reports, Search, SOQL, SOSL” (Restriction Rules). And it’s permanent: “This behavior is similar to how you can filter results in a list view or report, except that it’s permanent” (same page).

Another use I like: a soft-deleted flag. Mark records as deleted instead of deleting them, and a restriction rule hides them from everyone except your admins.

Restriction rules don’t work on every object, and you don’t get many:

  • Objects. “Restriction rules are available only for custom objects, external objects, quotes, contracts, events, tasks, time sheets, and time sheet entries” (Restriction Rules). Not accounts, not cases, not opportunities. For contracts, tasks and events, Salesforce says it’s often the best way: access to them “can be difficult to make truly private using organization-wide defaults” (same page).
  • How many. “You can create up to two active restriction rules per object in Enterprise and Developer editions and up to five active restriction rules per object in Performance and Unlimited editions” (same page). Two barrels in the shotgun.
  • One per user. Configure the rules “so that only one active rule applies to a given user.” Salesforce doesn’t check this for you, and if two rules apply, “only one of the active rules is observed” (same page). You don’t choose which one. So you, as the designer, make sure only one can ever match.
  • Simple criteria. “Restriction rules support only the EQUALS operator. The use of AND and OR operators isn’t supported. The use of formulas isn’t supported” (Restriction Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).
  • Not the children. “Creating a restriction rule for an object doesn’t automatically restrict access to its child objects” (same page).
  • Turn off Classic. Salesforce “can’t guarantee that restriction rules work as intended for end users who are in the Salesforce Classic experience” (Restriction Rules).

Two things go straight past it, and they’re two you already know from this chapter. “Restriction rules aren’t applied for code executed in System Mode.” And “Users with the View All Records or View All Data permissions can view all records regardless of restriction rules” (Restriction Rule Considerations). Way 13 and way 17 again.

So if code in system mode shows records to a user, a restriction rule won’t stop it. Check both together.

Scoping rules look similar and do something quite different. Salesforce: “Scoping rules let you control the records that your users see in list views, reports, and SOQL queries based on criteria that you select… Users can switch the set of records they’re seeing as needed” (Scoping Rules (opens in a new tab), Salesforce Help, checked 2026-11-01).

The key words: “they don’t restrict the access that your users have to records. Your users can still open and report on all the records that they can access according to your org’s sharing settings” (same page). It’s a filter, not security.

In my demo, I add a scoping rule on accounts: if the user’s “hot only” box is checked, show accounts rated Hot. In a list view, the user gets an extra choice, filter by scope. Pick it, and they see only hot accounts. Pick the standard list view, and they see them all again.

So you go to all that effort, and the user can turn it off. And why would a user turn on something that restricts their records? Restriction rules are powerful. Scoping rules are a nice to have: a way to help people focus, for example on their own agency or division, never a way to keep anything from them.

Two details. Scoping rules are “available for custom objects, accounts, cases, contacts, events, leads, opportunities, and tasks,” in Performance, Unlimited and Developer editions. And the same one-rule-per-user warning applies to them (Scoping Rules).

Put the two in order, and you have the whole set. Sets 1 to 5 open records. A restriction rule narrows them, for good. A scoping rule sets what list views and reports show first, and the user can switch it.

And neither one is in the share table. A restriction rule writes no row and removes none. It filters what the share table opened. So when someone asks why a user can’t see a record they’ve been shared, check the restriction rules on the object before you check anything else.

Open, then narrow Open, then narrow. First, Sets 1 to 5 open records: defaults, rules, teams, code and the rest. Then Set 6 narrows them. A restriction rule leaves only the records that match, always. Then a scoping rule sets what list views and reports show first, and the user can switch it. Below the restriction rule: not narrowed are View All, Modify All, and code in system mode. Footnote: a restriction rule writes no row and removes none; it filters what the share table opened. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.56.0", "built": "2026-10-30", "id": "DGM-SVA-WS-14", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} SETS 1 TO 5 OPEN SET 6 NARROWS What sharing opens defaults, rules, teams, code… Restriction rule only records that match · always Scoping rule list views and reports first · user can switch Not narrowed View All, Modify All, code in system mode then narrowed then focused A restriction rule writes no row and removes none: it filters what the share table opened. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

My deck had a third card in this set: custom code. Make the object Private, build a Lightning web component, and have its Apex read in system mode and decide what to show. It’s the last resort, when no sharing mechanism and no restriction rule can express the rule.

It’s now in Set 5, as way 17, and chapter 4, module 5 built one. Know the price: once the record is Private, you won’t get reports, list views or dashboards for it. Everything the user sees comes through your component.

Chapter 16, Taking Access Away: Restriction and Scoping Rules, takes these apart: designing the user and record criteria, keeping one rule per user, performance, external objects, and testing. For now, know the two, and know which one is security.

  • Whether the design should open less in the first place, before reaching for a restriction rule.
  • For each restriction rule: the object, the user criteria, the record criteria, and proof that only one rule can match each user.
  • Which users hold View All or run code in system mode on those objects, since the rule won’t narrow them.
  • Whether a scoping rule helps people focus, knowing it secures nothing.
  • When the last resort, a Private object behind a component, is worth losing reports and list views.

Beyond the exam: what AI changes. A restriction rule applies to an agent’s user like any other user, through SOQL and search. That makes it a useful guardrail: a rule that hides soft-deleted or confidential records from the agent’s user keeps them out of its answers. But only if the agent’s actions don’t run in system mode. A scoping rule is no guardrail at all. Chapter 20 covers agents.