Restricting Sensitive Data in Salesforce with Restriction Rules

Introduction

As part of the Summer ‘21 Release, Salesforce announced the new Restriction Rules (Beta) feature. This new feature provides an additional layer of security on top of the existing OWDs and Sharing Rules. It allows Admins to restrict access to sensitive records for certain users by setting up the filter conditions in the Restriction Rules. By the end of this blog, you will have an understanding of Restriction Rules and when to use this new feature to provide an extra layer of security to protect the data in your Salesforce org.

Why Use Restriction Rules?

Restriction rules help Administrators to limit access to records of certain objects within Salesforce. This can be illustrated with an example. Consider the following situation:

• An organization uses Salesforce Account records to hold the company information of clients
• The Organization-Wide-Default (OWD) is set to Public Read/Write
• A custom object called ‘Passbook’ is related to the Account in a Master-Detail relationship and tracks the Company’s bank details and the transactions made
• The Passbook records hold confidential information about the Customer, which should be accessible only by users with the “Finance” profile, and restricted for other users who don’t need access to such sensitive information

Until Summer ‘21, in order to set the access levels for Objects in Salesforce, we have used the OWDs and Sharing Rules in the org. With those existing features, users with access to a parent object automatically gain access over the child object(s) if they are related in a Master-Detail Relationship. In the example, as the Passbook Object is related to Account in a Master-Detail relationship and the OWD for the Account is Public Read/Write, all users would gain access to the Passbook records even when the OWD of Passbook Object is set to private.

With the Summer ‘21 Release update on Restriction Rules, accessibility can be further controlled on certain objects by restricting the users from accessing non-essential data. With our Passbook example, a Restriction Rule can be created on top of the OWD and Sharing Rules in such a way that the only users who require access will be able to see the Passbook records based on the filter criteria set in the Restriction Rules, and other users will be restricted from accessing it.

Fig 1: Filtering using Restriction Rules (Source: Salesforce Developer Blog)

When To Use Restriction Rules?

The main purpose of the Restriction Rules (Beta) is to control access to a specific set of records for certain users. All the existing sharing configurations like the OWDs, Sharing Rules and Territory Sharing, etc., are used to extend the user’s accessibility for Objects. This new Restriction Rule feature is the advanced configuration that allows the admins to restrict accessibility for users.

When a Restriction Rule is applied to a user, the record for which they had “Read” access through their sharing settings is further reduced to only records that match the recordFilter. This behaviour is similar to how you can filter results in a list view or report, except that it’s permanent. In our example, without a Restriction Rule, all the users gained access to the Passbook records as the Account has Public Read/Write access. With the new Restriction Rules in place, the access to the Passbook records will be limited to the Users with the “Finance” profile.

 

Fig 2: Record accessibility before Restriction Rules (Source: Salesforce Developer Blog)

 

Fig 3: Record accessibility after Restriction Rules (Source: Salesforce Developer Blog)

How To Create Restriction Rules

Currently, the Restriction Rules are managed only through Tooling and Metadata APIs and there is no Administrator UI in Setup to create them. Salesforce has provided ample help articles and developer blogs on the steps to create Restriction Rules and they can be referenced here: Developer Blog on Restriction Rules. Apart from the steps to configure, Salesforce extends the support with a handful of examples with sample code for each use case which can be found here.

Fig 4: Sample Restriction Rule

Considerations For Restriction Rules

As Restriction Rule is a new Beta feature from Salesforce, there are a few limitations to be noted before implementing this feature. Some highly important considerations are listed below, and additional considerations can be found here.

• The Restriction Rules is currently a Beta Service and customers may opt to try such Beta Service on their sole discretion
• This feature is available only for custom objects, contracts, tasks, and events
• You can create up to two Restriction Rules per object in Enterprise and Developer Editions and up to five Restriction Rules per object in Performance and Unlimited Editions
• Creating a Restriction Rule for an object doesn’t automatically restrict access to its child objects
  • For example, if you create a Restriction Rule on the Passbook object, the access doesn’t change for its child custom Object(s) (in a Master-Detail relationship). To address data access for those child objects, you must use other sharing mechanisms.

Conclusion

Restriction Rules enable the Admins to configure the access levels for custom objects, contracts, tasks, and events. In our example, we demonstrated that these rules are useful for restricting access to the detail records in a Master-Detail relationship. By configuring the filters in the Restriction Rule, the confidential information will be restricted to certain users and hidden for users who don’t require access. This powerful configuration is currently a Beta feature and it will become Generally Available (GA) in the near future, so stay tuned for more updates.

Resources

Release Notes
Restriction Rules Guide
Considerations for Restriction Rules