Restriction Rules and Scoping Rules
5 minutes
5 Questions
Restriction Rules and Scoping Rules are two record-access features in Salesforce that complement the standard sharing model (org-wide defaults, role hierarchy, sharing rules, manual sharing). Both are covered in the Platform Administrator II exam under Security and Access. Restriction Rules let admins limit the records a specified group of users can see, even when the sharing model would otherwise grant them access. They act as a filter on top of existing access: a user sees only records that match the rule's record criteria (for example, Contracts where Region__c equals the user's Region__c). They are especially useful for custom objects, external objects, contracts, events, tasks, timesheets, and timesheet entries. Key traits: a user must be assigned by a user criteria (such as a profile, permission set, or user field), only one active restriction rule can apply to a user per object, record visibility is enforced in list views, reports, search, lookups, and APIs, and they cannot grant access—only restrict it. Up to two active rules per object are allowed (more with extra licensing in some editions). They are ideal when org-wide defaults are Public Read Only but a subset of users should see only their own slice of data. Scoping Rules, by contrast, do not change security. They define a default scope of records a user sees, helping users focus on relevant records in list views, related lists, lookups, and search results. Users can still access out-of-scope records if the sharing model allows (for instance, by navigating to a direct URL or report). Scoping rules apply to standard and custom objects such as Account, Case, Contact, Event, Lead, Opportunity, and Task, and are configured with user criteria and record criteria, similar to restriction rules. In summary: Restriction Rules enforce security by hiding records; Scoping Rules improve usability by filtering what users see by default without removing access. Both are configured via Object Manager, require Enterprise Edition or higher, and are evaluated after standard sharing calculations.
Restriction Rules and Scoping Rules – Salesforce Advanced Administrator Guide
1. Why This Topic Matters
Record access in Salesforce has traditionally been an additive model: Organization-Wide Defaults (OWD) set the baseline, and then role hierarchy, sharing rules, manual sharing, teams, and Apex sharing all open up access. Nothing in that classic model lets you take access away from a specific group of users below what the sharing model already grants, and nothing lets you control which records a user sees by default without changing their actual access. Restriction Rules and Scoping Rules were introduced to fill exactly those gaps.
On the Advanced Administrator exam this topic sits inside the Security and Access objective. Questions test whether you can (a) recognise when the classic sharing tools are the wrong answer, (b) choose correctly between a restriction rule and a scoping rule, and (c) remember the limitations – supported objects, editions, limits, and how the rules interact with existing sharing. Because the two features look almost identical in Setup (both use User Criteria and Record Criteria), the exam loves to test the difference in effect.
2. What Restriction Rules Are
A Restriction Rule is a filter applied on top of the existing sharing model that reduces the set of records a specified group of users can access. Think of it as a subtractive layer: the user must already have access through OWD or sharing, and then the restriction rule says of those records, you may only see the ones that meet this criteria. Records that fail the record criteria become invisible to the user everywhere – list views, related lists, lookups, search, reports, SOQL/SOSL, and the API. It is not simply a display setting; it is true access restriction.
Each restriction rule has three parts:
• User Criteria – who the rule applies to (for example, a User field such as Profile, Role, a custom field like Region__c, or a permission). Only users matching this criteria are affected.
• Record Criteria – which records remain visible to those users (for example, Owner equals the current user, or Region__c equals the user's Region__c). You can compare a record field to a literal value or to a $User merge field.
• Active flag – rules can be built and tested while inactive.
Key characteristics to memorise:
• Supported objects: custom objects, external objects, Contracts, Events, Tasks, Time Sheets, and Time Sheet Entries. Standard objects such as Account, Contact, Opportunity, Case and Lead are not supported for restriction rules (a classic distractor). Always check the latest release notes, because Salesforce expands the list over time.
• Editions: Enterprise, Performance, Unlimited and Developer.
• Limits: up to 2 active restriction rules per object in Enterprise and Developer editions, and up to 5 active rules per object in Performance and Unlimited.
• They apply to any user who matches the user criteria, including users with powerful permissions, so build user criteria carefully to avoid accidentally hiding records from administrators.
• They cannot grant access. If a user cannot see a record through OWD or sharing, a restriction rule does not help; it only narrows what is already visible.
• Typical use case: Activities. Because Task and Event access is controlled by the parent record and the Controlled by Parent OWD, users often see tasks they should not. A restriction rule on Task with record criteria Owner ID equals $User.Id ensures each user sees only their own tasks.
• Other classic scenarios: regional custom object records (users in EMEA only see EMEA records even though OWD is Public Read Only), confidential contracts, or time sheets visible only to the owner and manager.
3. What Scoping Rules Are
A Scoping Rule does not change what a user is allowed to access. Instead it sets a default scope – a default filter – so that list views, search results, lookups, related lists and reports initially show only the records that are most relevant to that user. The user keeps full access to every record they are entitled to and can switch the scope off (for example, by toggling the scoping rule filter in a list view) or open a record directly by URL. Scoping rules are about focus and productivity, not security.
Scoping rules use the same structure – User Criteria, Record Criteria, Active flag – which is exactly why the exam tests whether you understand the behavioural difference.
Key characteristics to memorise:
• Supported objects: custom objects, Account, Case, Contact, Event, Lead, Opportunity and Task. Note that scoping rules cover the core CRM standard objects that restriction rules do not.
• Editions: Performance and Unlimited (plus Developer). Enterprise edition does not include scoping rules – another frequent distractor.
• Limited number of active scoping rules per object (currently 2).
• Users can see the scoped filter indicator and remove it; the rule never blocks access.
• Typical use case: a global sales org where OWD on Account is Public Read/Write (so everyone legitimately needs access), but reps in Japan want list views and search to default to Japanese accounts. A scoping rule with user criteria Country equals Japan and record criteria BillingCountry equals $User.Country achieves this without touching sharing.
4. How They Work – Order of Evaluation
Think of record access as a pipeline:
1. Object permissions (profile / permission set) – can the user access the object at all?
2. OWD + sharing (role hierarchy, sharing rules, manual sharing, teams, Apex sharing) – which records does the user have a sharing entry for? This layer only ever adds access.
3. Restriction rule – from the records granted in step 2, remove any that fail the record criteria for users matching the user criteria. This layer only ever subtracts access.
4. Scoping rule – from the final accessible set, apply a default filter in list views, search, reports and lookups. Access is unchanged; the user can widen the view.
5. Field-level security and page layouts – which fields the user sees on records they can access.
Both rule types are configured in Setup > Object Manager > [Object] > Restriction Rules or Scoping Rules, and both can be deployed with Metadata API (RestrictionRule and ScopingRule types). Both support $User merge fields in record criteria so a single rule can serve many users dynamically (for example, Region__c equals $User.Region__c) instead of creating one rule per region.
5. Comparing the Classic Tools
• OWD – baseline for everyone; cannot target a subset of users.
• Sharing rules – grant extra access to groups; cannot remove access.
• Role hierarchy – managers inherit subordinate access; cannot carve out exceptions.
• Permission sets / profiles – object and field permissions, not record-level filters.
• Restriction rules – remove record access for a specific user set below what sharing grants.
• Scoping rules – change default visibility (focus) without changing access.
• List view filters – user- or admin-defined, but do not follow the user into search, reports or lookups and can be edited; scoping rules apply consistently across the UI.
6. Worked Scenarios
Scenario A: Support agents must only see Tasks they own, even though Tasks are visible through their Cases. Classic sharing cannot hide them. Answer: Restriction rule on Task, user criteria Profile equals Support Agent, record criteria OwnerId equals $User.Id.
Scenario B: Account OWD is Public Read/Write for collaboration, but reps complain that search and list views are cluttered with accounts from other countries. They must still be able to open any account when needed. Answer: Scoping rule on Account. A restriction rule would be wrong because it would remove access and, in any case, Account is not a supported object for restriction rules.
Scenario C: A custom object Project__c has OWD Public Read Only. Contractors (a custom Boolean on User) must see only projects where Visibility__c equals External. Answer: Restriction rule on Project__c with user criteria Is_Contractor__c equals True and record criteria Visibility__c equals External.
Scenario D: Users in Enterprise edition ask for default filtered list views across Opportunities tied to their division. Answer: Scoping rules are not available in Enterprise edition; recommend an upgrade or alternative approaches such as division-based list view filters.
Scenario E: A user cannot see a Contract that was shared with their role. An admin recently activated a restriction rule on Contract. Answer: Check the restriction rule first – a restriction rule can hide records even when sharing grants access. Deactivate or adjust the record criteria.
7. Exam Tips: Answering Questions on Restriction Rules and Scoping Rules
• Read for the verb. If the requirement says users must not see, should be prevented from accessing, or only see certain records, think restriction rule. If it says users should by default see, focus on, or reduce clutter while still being able to access other records, think scoping rule.
• Check the object. Account, Contact, Opportunity, Lead, Case: restriction rule is not an option – look for scoping rule or a sharing redesign. Task, Event, Contract, Time Sheet, custom or external object: restriction rule is possible.
• Check the edition. Scoping rules require Performance or Unlimited; restriction rules are available from Enterprise upward. An answer that proposes scoping rules in an Enterprise org is a trap.
• Remember the limits. 2 active restriction rules per object (Enterprise/Developer), 5 (Performance/Unlimited). If a question describes needing many regional variations, the correct answer uses $User merge fields in a single rule rather than many rules.
• Restriction rules subtract; sharing rules add. Any answer suggesting a restriction rule to give access, or a sharing rule to remove access, is wrong.
• Scoping rules are not security. If the question involves compliance, confidentiality or regulatory requirements, a scoping rule is never sufficient because users can toggle it off.
• Activities are the signature use case. When a question mentions users seeing Tasks or Events they should not because of Controlled by Parent, the answer is almost always a restriction rule on Task or Event.
• Troubleshooting questions. When a user with apparently valid sharing cannot see a record on a supported object, include active restriction rules in your diagnosis before assuming a sharing problem.
• Eliminate the lookalikes. Distractors often include OWD changes (affect everyone), list view filters (not applied in search or reports and user-editable), permission sets (object/field level, not record filters), and Apex sharing (adds access only).
• Watch for the word default. It is the strongest single clue pointing to scoping rules.
8. Quick Reference Summary
• Restriction Rule: subtractive, hides records, applies everywhere (UI, search, reports, API), supported on custom/external objects, Contract, Event, Task, Time Sheet, Time Sheet Entry; Enterprise+; 2 or 5 active per object.
• Scoping Rule: default filter only, user can toggle off, no change to access, supported on custom objects plus Account, Case, Contact, Event, Lead, Opportunity, Task; Performance/Unlimited; limited active rules per object.
• Both: User Criteria + Record Criteria + Active flag; configured per object in Object Manager; support $User merge fields; deployable via Metadata API.
Master the distinction between removing access and focusing the view, memorise the supported object lists and editions, and you will handle every Restriction Rule and Scoping Rule question the Advanced Administrator exam can present.
Record access in Salesforce has traditionally been an additive model: Organization-Wide Defaults (OWD) set the baseline, and then role hierarchy, sharing rules, manual sharing, teams, and Apex sharing all open up access. Nothing in that classic model lets you take access away from a specific group of users below what the sharing model already grants, and nothing lets you control which records a user sees by default without changing their actual access. Restriction Rules and Scoping Rules were introduced to fill exactly those gaps.
On the Advanced Administrator exam this topic sits inside the Security and Access objective. Questions test whether you can (a) recognise when the classic sharing tools are the wrong answer, (b) choose correctly between a restriction rule and a scoping rule, and (c) remember the limitations – supported objects, editions, limits, and how the rules interact with existing sharing. Because the two features look almost identical in Setup (both use User Criteria and Record Criteria), the exam loves to test the difference in effect.
2. What Restriction Rules Are
A Restriction Rule is a filter applied on top of the existing sharing model that reduces the set of records a specified group of users can access. Think of it as a subtractive layer: the user must already have access through OWD or sharing, and then the restriction rule says of those records, you may only see the ones that meet this criteria. Records that fail the record criteria become invisible to the user everywhere – list views, related lists, lookups, search, reports, SOQL/SOSL, and the API. It is not simply a display setting; it is true access restriction.
Each restriction rule has three parts:
• User Criteria – who the rule applies to (for example, a User field such as Profile, Role, a custom field like Region__c, or a permission). Only users matching this criteria are affected.
• Record Criteria – which records remain visible to those users (for example, Owner equals the current user, or Region__c equals the user's Region__c). You can compare a record field to a literal value or to a $User merge field.
• Active flag – rules can be built and tested while inactive.
Key characteristics to memorise:
• Supported objects: custom objects, external objects, Contracts, Events, Tasks, Time Sheets, and Time Sheet Entries. Standard objects such as Account, Contact, Opportunity, Case and Lead are not supported for restriction rules (a classic distractor). Always check the latest release notes, because Salesforce expands the list over time.
• Editions: Enterprise, Performance, Unlimited and Developer.
• Limits: up to 2 active restriction rules per object in Enterprise and Developer editions, and up to 5 active rules per object in Performance and Unlimited.
• They apply to any user who matches the user criteria, including users with powerful permissions, so build user criteria carefully to avoid accidentally hiding records from administrators.
• They cannot grant access. If a user cannot see a record through OWD or sharing, a restriction rule does not help; it only narrows what is already visible.
• Typical use case: Activities. Because Task and Event access is controlled by the parent record and the Controlled by Parent OWD, users often see tasks they should not. A restriction rule on Task with record criteria Owner ID equals $User.Id ensures each user sees only their own tasks.
• Other classic scenarios: regional custom object records (users in EMEA only see EMEA records even though OWD is Public Read Only), confidential contracts, or time sheets visible only to the owner and manager.
3. What Scoping Rules Are
A Scoping Rule does not change what a user is allowed to access. Instead it sets a default scope – a default filter – so that list views, search results, lookups, related lists and reports initially show only the records that are most relevant to that user. The user keeps full access to every record they are entitled to and can switch the scope off (for example, by toggling the scoping rule filter in a list view) or open a record directly by URL. Scoping rules are about focus and productivity, not security.
Scoping rules use the same structure – User Criteria, Record Criteria, Active flag – which is exactly why the exam tests whether you understand the behavioural difference.
Key characteristics to memorise:
• Supported objects: custom objects, Account, Case, Contact, Event, Lead, Opportunity and Task. Note that scoping rules cover the core CRM standard objects that restriction rules do not.
• Editions: Performance and Unlimited (plus Developer). Enterprise edition does not include scoping rules – another frequent distractor.
• Limited number of active scoping rules per object (currently 2).
• Users can see the scoped filter indicator and remove it; the rule never blocks access.
• Typical use case: a global sales org where OWD on Account is Public Read/Write (so everyone legitimately needs access), but reps in Japan want list views and search to default to Japanese accounts. A scoping rule with user criteria Country equals Japan and record criteria BillingCountry equals $User.Country achieves this without touching sharing.
4. How They Work – Order of Evaluation
Think of record access as a pipeline:
1. Object permissions (profile / permission set) – can the user access the object at all?
2. OWD + sharing (role hierarchy, sharing rules, manual sharing, teams, Apex sharing) – which records does the user have a sharing entry for? This layer only ever adds access.
3. Restriction rule – from the records granted in step 2, remove any that fail the record criteria for users matching the user criteria. This layer only ever subtracts access.
4. Scoping rule – from the final accessible set, apply a default filter in list views, search, reports and lookups. Access is unchanged; the user can widen the view.
5. Field-level security and page layouts – which fields the user sees on records they can access.
Both rule types are configured in Setup > Object Manager > [Object] > Restriction Rules or Scoping Rules, and both can be deployed with Metadata API (RestrictionRule and ScopingRule types). Both support $User merge fields in record criteria so a single rule can serve many users dynamically (for example, Region__c equals $User.Region__c) instead of creating one rule per region.
5. Comparing the Classic Tools
• OWD – baseline for everyone; cannot target a subset of users.
• Sharing rules – grant extra access to groups; cannot remove access.
• Role hierarchy – managers inherit subordinate access; cannot carve out exceptions.
• Permission sets / profiles – object and field permissions, not record-level filters.
• Restriction rules – remove record access for a specific user set below what sharing grants.
• Scoping rules – change default visibility (focus) without changing access.
• List view filters – user- or admin-defined, but do not follow the user into search, reports or lookups and can be edited; scoping rules apply consistently across the UI.
6. Worked Scenarios
Scenario A: Support agents must only see Tasks they own, even though Tasks are visible through their Cases. Classic sharing cannot hide them. Answer: Restriction rule on Task, user criteria Profile equals Support Agent, record criteria OwnerId equals $User.Id.
Scenario B: Account OWD is Public Read/Write for collaboration, but reps complain that search and list views are cluttered with accounts from other countries. They must still be able to open any account when needed. Answer: Scoping rule on Account. A restriction rule would be wrong because it would remove access and, in any case, Account is not a supported object for restriction rules.
Scenario C: A custom object Project__c has OWD Public Read Only. Contractors (a custom Boolean on User) must see only projects where Visibility__c equals External. Answer: Restriction rule on Project__c with user criteria Is_Contractor__c equals True and record criteria Visibility__c equals External.
Scenario D: Users in Enterprise edition ask for default filtered list views across Opportunities tied to their division. Answer: Scoping rules are not available in Enterprise edition; recommend an upgrade or alternative approaches such as division-based list view filters.
Scenario E: A user cannot see a Contract that was shared with their role. An admin recently activated a restriction rule on Contract. Answer: Check the restriction rule first – a restriction rule can hide records even when sharing grants access. Deactivate or adjust the record criteria.
7. Exam Tips: Answering Questions on Restriction Rules and Scoping Rules
• Read for the verb. If the requirement says users must not see, should be prevented from accessing, or only see certain records, think restriction rule. If it says users should by default see, focus on, or reduce clutter while still being able to access other records, think scoping rule.
• Check the object. Account, Contact, Opportunity, Lead, Case: restriction rule is not an option – look for scoping rule or a sharing redesign. Task, Event, Contract, Time Sheet, custom or external object: restriction rule is possible.
• Check the edition. Scoping rules require Performance or Unlimited; restriction rules are available from Enterprise upward. An answer that proposes scoping rules in an Enterprise org is a trap.
• Remember the limits. 2 active restriction rules per object (Enterprise/Developer), 5 (Performance/Unlimited). If a question describes needing many regional variations, the correct answer uses $User merge fields in a single rule rather than many rules.
• Restriction rules subtract; sharing rules add. Any answer suggesting a restriction rule to give access, or a sharing rule to remove access, is wrong.
• Scoping rules are not security. If the question involves compliance, confidentiality or regulatory requirements, a scoping rule is never sufficient because users can toggle it off.
• Activities are the signature use case. When a question mentions users seeing Tasks or Events they should not because of Controlled by Parent, the answer is almost always a restriction rule on Task or Event.
• Troubleshooting questions. When a user with apparently valid sharing cannot see a record on a supported object, include active restriction rules in your diagnosis before assuming a sharing problem.
• Eliminate the lookalikes. Distractors often include OWD changes (affect everyone), list view filters (not applied in search or reports and user-editable), permission sets (object/field level, not record filters), and Apex sharing (adds access only).
• Watch for the word default. It is the strongest single clue pointing to scoping rules.
8. Quick Reference Summary
• Restriction Rule: subtractive, hides records, applies everywhere (UI, search, reports, API), supported on custom/external objects, Contract, Event, Task, Time Sheet, Time Sheet Entry; Enterprise+; 2 or 5 active per object.
• Scoping Rule: default filter only, user can toggle off, no change to access, supported on custom objects plus Account, Case, Contact, Event, Lead, Opportunity, Task; Performance/Unlimited; limited active rules per object.
• Both: User Criteria + Record Criteria + Active flag; configured per object in Object Manager; support $User merge fields; deployable via Metadata API.
Master the distinction between removing access and focusing the view, memorise the supported object lists and editions, and you will handle every Restriction Rule and Scoping Rule question the Advanced Administrator exam can present.
Test mode:
Admin II - Restriction Rules and Scoping Rules Example Questions
Test your knowledge of Restriction Rules and Scoping Rules
Question 1
Which statement best describes how scoping rules differ from restriction rules in Salesforce record access?
Question 2
At Cloud Kicks, the org-wide default for the custom Service Request object is Public Read Only. Regional managers want reps to see only their own region's requests when they open list views and reports. Reps must still be able to find and open requests from other regions when covering for absent colleagues. One administrator proposes a restriction rule and another proposes a scoping rule. Which recommendation should the advanced administrator support?
Question 3
At Northern Trail Outfitters, the org-wide default for the custom Inspection object is Public Read Only because several other teams must read every record. The administrator set up a scoping rule so field inspectors see their own region's inspections by default. Managers now report that inspectors can still find and open inspections from other regions. Inspectors must be unable to reach other regions' records, and the org-wide default must stay as it is. What should the administrator do?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Restriction Rules and Scoping Rules questions
26 questions (total)
Other Security and Access concepts
Account Hierarchies and Business Account ModelsAccount Teams, Opportunity Teams and Manual SharingConnected App Access PoliciesContacts to Multiple AccountsControlled by Parent Access on Detail RecordsCustom Profiles Versus Permission SetsDelegated AdministrationEmail Template Folder AccessEnterprise Territory Management Record AccessField-Level Security Across Profiles and Permission SetsLogin Hours, Login IP Ranges and Trusted IP RangesMulti-Factor Authentication for UsersOrganization-Wide Defaults and External Sharing ModelOwner-Based and Criteria-Based Sharing RulesPermission Set Groups and Muting Permission SetsPerson AccountsReport and Dashboard Folder AccessRole Hierarchy and Grant Access Using HierarchiesSession Settings and High-Assurance SessionsSingle Sign-On with SAML and Identity ProvidersTroubleshooting Record Access with Sharing HierarchyView All, Modify All and Administrative Permissions