Traditionally, to control the visibility of records in Salesforce, we used to start with the most restrictive setting (i.e. setting OWD to Private for an object) and then opening up the access using various features like role hierarchy, sharing rules, teams etc.
Consider the following diagram. Before Restriction rules, we started with the most restrictive setting and then opened up access using various features.
(Image Source: Restriction Rule Developer Guide)
But, now with Winter ’22 Release of Salesforce, we can also define a rule to restrict the visibility of records. For example, even if we have defined the OWD to Public Read or Public Read/Write on an object, we can now add restriction rules to hide certain records from certain users.
(Image Source: Restriction Rule Developer Guide)
So, What Are Restriction Rules?
Restriction Rules allow admin to restrict the visibility of selected records from selected group of users. It went GA (Generally Available) in Salesforce Winter ‘22 Release.
Which Objects are Supported for Restriction Rules?
As of now only the following objects are supported for Restriction Rules:
- Custom Objects
- Time Sheets
- Timesheet Entries
Where are Restriction Rules Applied?
Once defined, Restriction Rules are applied to the following Salesforce features:
- List Views
- Related Lists
What are the Current Limitations & Considerations for Restriction Rules?
- Only two Restriction Rules can be created on the supported objects in Enterprise Edition & five in Unlimited & Performance Edition
- Only below data types are supported in the recordFilter and userCriteria fields:
- Restriction rules support only the EQUALS operator. The AND, OR, or any other operators aren’t supported.
- The use of formulas isn’t supported.
- You can use a change set to move restriction rules from one org to another.
- If you include IDs in your recordFilter or userCriteria fields that are specific to your Salesforce org (such as a role, record type, or profile ID), you must modify these IDs in the target org if different from the org where the restriction rules were originally created.
Ok, that’s enough talk. Now, let’s take a look at Restriction Rules in action in just under 10 minutes.
References & Useful URLs
- Restriction Rules Developer Guide
- Post from Salesforce Engineering (10 mts) – Restriction Rules: Complementing Salesforce’s Record Access Control Mechanism (we all know Salesforce sharing works by creating records in a “Share” object for each main object in Salesforce. This post lets you look under the hood to understand how Restriction rules work.)
- Blog Post (15 mts) – 22 Ways to Share Records in Salesforce
10 thoughts on “Step By Step Guide to Using Restriction Rules in Salesforce”
Hi, Restrictions Rules is not displayed on my custom object.
You may want to take a look at the URL https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5 and go through all the various considerations and limitations for Restriction Rules. If you are still not able to get an answer on why it is not displayed on your custom object, I will recommend logging a case with Salesforce Support.
Thanks for your post. I have been following you for almost more than 4 years. I do have a question about this.
As per the salesforce documentation, Restriction rules do not restrict the record access means the user will have access to records and he can have them by searching for the specific record which has been hidden through restriction rules.
I was looking into the use case where you are trying to restrict the Contracts which are sensitive. But users can still access the sensitive contracts by searching specific records ?? Please correct me if I am wrong.
Also, could you please share more use cases related to this feature?
Restriction rules do restrict you from accessing records. So you can stop the users from accessing sensitive contracts by using restriction rules and in this blog post we are doing exactly that.
The feature that you are referring to is called “Scoping Rules”, which does not restrict you from accessing records. It just controls the default records that your users see based on criteria that you select. Here is the URL where you can find more information about scoping rules – https://developer.salesforce.com/docs/atlas.en-us.236.0.scoping_rules.meta/scoping_rules/scoping_rules_about.htm
Hi, how can I use blank value or null value in Restriction rule with field type String.
Hi Alok, it doesn’t look like you can use blank value with “String” field type directly in restriction rules. But what you can try is create a formula field of “Checkbox” type and set the value of this field to true or false based on whether the string field is empty or not. Then use this formula field in the restriction rule. See if this will work.
Thanks for the solution but I can see that we can’t use formula field in the restriction rule as of the Winter ’22 release. Can you help me to find any another way to achieve this
If the formula field does not work, then you can create a regular custom field and populate that using Flows. Restriction rules being a new feature has quite a few restrictions currently. 🙂 Hopefully in future releases, Salesforce will add more features and functionalities.
Thanks for the walk through Ashish, great to see that working in an org – this would have saved a lot of work had it been in a previous release! I can think of a lot of use cases.
I got caught out with finding the Profile ID as I just clicked the profile in set up and copied the ID number rather than following your instructions. I didn’t realise that when you do that you need to strip out the %2F from the profile ID (as per this help article: https://help.salesforce.com/s/articleView?id=000312782&type=1). Once I had the Profile ID correctly it all worked as per the demo – thanks.
Thanks for sharing the link, Mary. Yes, even I noticed that when you go to the profile directly in Salesforce UI, it adds extra characters to the profile id in the URL. That is why I included the steps to query the Id through Developer Console. 🙂
The concept of restriction rules sounds promising. But currently it has a lot of limitations. Hopefully in subsequent releases, Salesforce will make it more powerful.