Salesforce Security - Restriction Rules and Scoping Rules

1. Overview

Salesforce provides a very effective security model where we always start with the most restrictive access and then open up access using additional mechanisms like sharing rules, and manual sharing based on the requirements.

 

But there might be scenarios where we need to restrict access based on specific criteria. Salesforce recently introduced 2 approaches to support this requirement. Those are restriction rules and scoping rules. Let us see this in detail.

2. Restriction Rules - Overview

Using restriction rules we can apply an additional level of filter on top of records to which a specific user is having access.

3. Scoping Rules - Overview

Scoping rules help to filter the default records visible for a user based on specific criteria. But it is not preventing access to other records.

4. Compare Restriction Rules and Scoping Rules

5. Restriction Rule - Example

Company ABC is having Job Applications getting created through their company portal and synched to Salesforce. The recruitment team needs to work on these job Applications to process them. 

Visibility Requirement

We have a recruitment person assigned to each region and he should have visibility to Job Applications only in his region.

Job Application Organization-Wide Default is Private

All recruitment team members will be assigned to Recruitment Team Role.

Solution

Since OWD is private, We need to create sharing rule to share Job Applications with Recruitment Team. The traditional solution option is that, create public groups for recruiters based on region and share job applications based on criteria.

Now let us see how we can use restriction rules to share it with recruiters.

Step 1 - Create Sharing Rule to share all job Applications with the recruitment Team Role. All recruiters will be assigned with the "Recruitment Team" Role.

OWD:

Sharing Rule:

 Test Results

I got a Recruitment Team member called Recruitment manager with geography as "APAC"

Also, we have 2 Job Application got created as shown below, 1 belong to APAC and one belongs to EMEA. 

Since we have the sharing rule giving access to all records, this person can see both records now:

But our requirement is that he should see only records from APAC, since his geography is APAC.

Let us see how we can achieve this through the Restriction rule.

Restriction rule can be created from Set up->Object manager->Job Application -> Restriction rule-> New

Restriction Rule Name - >Geography Sharing

User Criteria - User.Goegraphy__c = APAC

Note that we can add only one criteria here. 

Record Criteria

Job_Application__c.Geography__c = APAC

Test Results

Now if we refresh the Recruitment Manager list view - we can see that he got access to only APAC record.

And if we try to access the record which got removed from list - he will get error as shown below:

Considerations

• At this moment we can create only a maximum of 5 Restriction rules per object. 
• And we cannot have AND or OR conditions in the criteria
• In record criteria, we cannot have picklist values

So keep all this in mind before solutioning your sharing.

6. Scoping Rule - Example

For the same example, we described above, suppose the same recruitment team needs to support all-region, but they want to work on a single region at a time. In that case, let us see how Scoping rules going to help us. We need to deactivate the Restriction rule first. After that follow the below steps:

Step 1 - Create Scoping rule

We can create scoping rule in the same way we created the restriction rule:

Go to setup->Object Manager->Job Application->Scoping Rules->New

Give a Label

Define User Criteria

Here we are going to define generic criteria to identify all users in the recruitment team. So criteria will be specified as User.Role = Recruitment Team

Define Record Filter Criteria

Here the user is always going to see records from geography which is the same as his geography.

Once this is saved, we need to update the filter criteria in the list view to reflect Scoping rule:

Test Results:

Now if we open the list view, he can see only APAC records which is his geography.

But if we go to recently viewed - he cans till see both records:

And if he opens EMEA record, he can still view it.

So Scoping rule - just restrict the displayed records currently, but do not block access to other records.

7. Adding additional flexibility to view records

Since we have got a global team handling the recruitment process, we need a mechanism to switch between regions and control visibility through scoping rules. 

To get this visibility we are using a list button associated with a screen flow to update the user's region on selection and display records based on that.

Let us see the flow first:

List button Created consuming this flow:

This is going to show a picklist with different region values and defaulted to the current user's region. Users can select some other region and at the backend user's record will be updated with a new region and scoping rule will take effect and the list view will point to new region records now.

Let us see how the list view is behaving now:

1. User's current region is APAC:

2. Job Application List view:

Shows APAC record

3. User clicks on Select Geography Button

4. User selects region as EMEA

5. User gets region updates message

6. On Finish user navigated to List view & It shows EMEA record

Conclusion - So user is getting flexibility now to switch between regions and concentrate on a single region at a time easily.

Video Explanation:

8. References

https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5

https://help.salesforce.com/s/articleView?id=security_scoping_rule.htm&type=5&language=en_US

https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_about.htm

https://developer.salesforce.com/docs/atlas.en-us.scoping_rules.meta/scoping_rules/scoping_rules_about.htm

https://trailhead.salesforce.com/trailblazer-community/groups/0F94S000000GzylSAC?tab=discussion&sort=LAST_MODIFIED_DATE_DESC - Community group