Build a Robust Security Architecture – Control Sensitive Records with Restriction Rules!

Last Updated on February 10, 2022 by Rakesh Gupta

What comes to your mind when someone asks – Can you please explain how security is set up in a Salesforce Org? If Organization-Wide Default (OWD) crossed your mind then, you belong to a group of savvy Salesforce users 😊!

For, when learning about securing a Salesforce Org, OWD is one of the first concepts – and a very important one at that – one learns to wrap one’s head around! This is so because, OWD dictates base-level sharing settings of records within an object. OWD settings ensure users can’t access records – even if they have access to an Object within which those records reside – without being specifically granted access to the records they do not own.

The following diagram shows the basic record security in Salesforce. In this, OWD plays a key role:

The only way to secure record data in Salesforce is to set up a restrictive OWD; everything else – like Role Hierarchy, Sharing Rule, Manual Sharing, Team Sharing, Enterprise Territory management – is used to open up access to records a user does not own.

For example, Alex Pisani is working as a Security Architect at Universal Containers. He has received a requirement from his Sales Director to set up users’ access to Lead records. Requirements: (1) only users that own the Lead’s records; and (2) users that are higher in the role hierarchy can access the Lead’s records.

The above business use case can be addressed by setting OWD to Private and leveraging role hierarchy.

However, just like not all five fingers on your hands are the same similarly, business requirements vary, and therefore, every requirement can’t be solved using a one-size-fits-all solution. For instance, below, let us take a look at a different example:

At Universal Containers, the Sales Director wants to promote healthy competition between Sales teams. As a result, he asks Alex, the Security Architect, to make sure that sales reps can’t see each other’s activities, even though these Activities – Task and Events – are on the same Account.

Find yourself thinking too hard for a solution? If so then, let me pre-warn you – Changing Tasks’ or Events’ OWD is not an option because it will impact other business units, as well many other business processes (custom or standard objects).

Introducing Restriction Rule

Restriction Rules work like an iron fist! They allow you to enhance your org security by enabling you to grant users access to only the records, and related Activities, that you want them to access. In other words, it gives you highly granular control over how you want to shell out access to users.

When you use the Restriction Rule, how much access a user gets to a record depends on two factors: (1) access to records via sharing settings plus (2) the criteria baked in the recordFilter of the Restriction Rule. This is the same as a User filter on the records in a report or list view.

Let’s review some examples where Restriction Rule might be helpful:

1. Only show the contracts that are owned by the logged-In users, regardless of where they are in the role hierarchy.
2. Make sure only selected users have access to Tasks and Events on a given Account, even if they have access to the Account’s record.
3. For custom objects, even if a user has access to the Master record, prevent his/her access to Detail records.

Yes, very powerful indeed!!

Configure Restriction Rule

You can now create and manage Restriction Rules in Setup as well as by using the Tooling API or Metadata API. Let’s start with a business use case.

Brenda David is working as a System Administrator at Universal Containers (UC). Her team is now implementing the Partnership admission process. As a result, Brenda created two objects with a Master-Detail relationship.

1. Partnership Request (Master)
2. Onboarding Process (Detail)

Brenda wants to design a solution for the following requirements:

1. Although everyone can see all Partnership & Onboarding Request records, the following exceptions apply:
   1. Sales reps can only see Onboarding Request records that they create.
   2. However, Sales reps are allowed to see all Partnership Request records.

Step-by-step instructions

The above business requirement can be solved by changing the relationship type, etc. However, Salesforce’s Best Practice dictates that we design the most optimal solution to address a requirement! Therefore the above requirement calls for the use of – you guessed it right! – the Restriction Rule! As you know, if someone has access to a Parent record, they automatically get access to Child records whenever the two objects are connected via a Master-Detail relationship. 

So, let us use the Restriction Rule to solve Brenda’s business requirement. Follow the steps below:

1. Click Setup.
2. In the Object Manager, type Onboarding Process.
3. Select Onboarding Process, then navigate to Restriction Rule.
4. Select Restriction Rule, then click New Rule.
5. Enter Rule Name and click the Next. The Full Name will auto-populate.
6. Select Is Active checkbox. Under User Criteria: Select which users this Restriction Rule applies to:
   1. Field: Title
   2. Operator: Equals
   3. Type: String
   4. Value: Sales Rep
7. Under Record Criteria: Select which records the specified users are allowed to see:
   1. Field: CreatedById
   2. Operator: Equals
   3. Type: Current User
   4. Value: UserId
8. In the end, Brenda’s Restriction Rule will look like the following screenshot:
9. Once everything looks good, click Save.

Things to Remember

• As of Winter’22 release, Restriction Rule only supports the following objects:
  • Task, Event, Contract, Custom object, TimeSheet, and TimeSheetEntry.
• You can create Restriction Rules via:
  • Tooling API
  • Metadata API
  • Salesforce Setup
• It is possible to deploy Restriction Rule using Change Sets.
• You can create up to two Restriction Rules per object in the Enterprise and Developer Editions and up to five Restriction Rules per object in Performance and Unlimited Editions.
• Check out this help article to find a comprehensive list of Restriction Rule considerations and limitations.

Formative Assessment:

I want to hear from you!  

What did you learn from this post, is it relevant to you, and how will you modify the concepts taught in the post for your own business processes? Share your tips in the comments!

Make a post and tag me on Twitter @automationchamp using #AutomationChampionFlow.

Proofreader: - Munira Majmundar