Salesforce new feature - Restriction Rule

on

Restriction Rule:


Security Setup in Salesforce Org:


When we talk about security setup in org, the first thing that comes into mind is OWD which is the base level sharing setting of records within an object. OWD ensures that users can't access records even if they have access to an object within which the records exists unless we specifically provide access using Role Hierarchy, sharing rules, manual sharing etc.

We are already familiar with this diagram which shows how Role Hierarchy, Sharing Rules, Manual Sharing etc. are used to open up the access to records a user doesn't own.




Example 1:
Suppose we got a requirement to setup user's access to Lead records making sure that only users that own the Leads' records get the access and the users that are higher in the role hierarchy can access the leads' records

So, what would be the solution in this case - setting the OWD as private and using role hierarchy.

Example 2:
Suppose we got a requirement to make sure that sales reps shouldn't be able to see each other's activities (Tasks and Events), even though these activities are on the same account. Here we can't think of making the OWD private for tasks and events because it will impact other business units, the process etc.

Salesforce introduces Restriction Rules which can help in such scenarios.


Restriction Rules:

Restriction Rules enhances the security by allowing certain users to access only specified records that is when we implement RR, the data that the user has access to through OWD, sharing rules and any other sharing mechanism is filtered by the criteria we specify in the record filter and user filter of the Restriction Rule.

This diagram clearly shows the same.




For Example:
We can prevent users from accessing records that may have sensitive data that isn't essential to their work. Here Restriction Rule can act as a filter to show the users what's essential.

When to use Restriction Rules:

One of the scenario is already mentioned above, similarly access to Contracts, Tasks, Event can be difficult to make truly private using OWD. So, creating Restriction Rule is the best way to set or configure the visibility

How do Restriction Rules affect other Sharing Settings?

How this affect other sharing settings has been diagrammatically shown here. Once RR is applied the data that they had read access to (suppose) through sharing settings is further scoped to only records matching the record filter. We can see how this looks like before and after RR has been applied.





More similar Example:


More similar example where RR can be applied are:

  • Allow Users to See Only Specified Record Type : This restriction rule allows the designated users to see only contracts that have a specified record type.
  • Allow Users to See Only Records That They Own :This restriction rule allows users with the designated profile to see only the tasks that they own.
  • Allow Users to See Only Records Owned by Same Role : This restriction rule allows active users to see only the events owned by users that have the same role. You can use dot notation to traverse object and field relationships in the recordFilter field.
  • Allow Users to See Only Records Owned by Same Profile : This restriction rule allows active users to see only the events owned by users that have the same profile. You can use dot notation to traverse object and field relationships in the recordFilter field.
  • Allow Users to See Records Based on a Custom Field : This restriction rule allows high-volume users to see only the contracts where the user's department matches the contract's department. This rule uses a custom field, Department__c, that must have the appropriate value set through Apex, Process Builder, workflows, or flows.

Scenarios like:
  • Suppose only selected users should have access to Tasks and Events on a given Account even if they have access to Accounts’ record.
  • For any of the custom object even if the user has access to Master record, prevent access to detail record.
  • Only show the records owned by the logged In user regardless of where they are in the role hierarchy.


How to configure Restriction Rules?


  • There are 3 ways we can create or manage RR that is from setup, tooling API, metadata API

  • Earlier we had 2 options that is through Tooling API and metadata API. Recently, as part of Winter'22 release, we can create RR from setup as well.

  • In Master-Details relationship, if someone has access to parent, they automatically get access to child records but currently, we have to restrict child record access and this is done using RR.


Steps:

  • Setup
  • Object Manager > Child Object
  • Select Restriction Rules > New Rule
  • Enter Rule Name > Next (Full Name will auto-populate)
  • Select Is Active checkbox (true)
  • Under User Criteria: Select which users this Restriction Rule applies to:
  • Field: Title, Operator: Equals, Type: String, Value: Analyst (Suppose)
  • Under Record Criteria: Select which records the specified users are allowed to see:
  • Field: CreatedById, Operator: Equals, Type: Current User, Value: UserId



Create RR using Tooling API and Metadata API

  • If we are comfortable using an API development application like postman etc. we can go for this way of creating RR.
  • You can use either the Tooling or Metadata API to create, retrieve, update, and delete restriction rules.

Steps:


  • Set a value for the FullName value (the full name of the associated metadata object in Metadata API). We don't support two consecutive underscores in the FullName field.
  • Include all other required fields.
{
    "FullName": "restrictionrulesalesteam",
    "Metadata": {
        "active": true,
        "description": "Sales team can see only task records with specified record type",
        "enforcementType": "Restrict",
        "masterLabel": "Sales Team Record Type",
        "recordFilter": "recordTypeId = '011xxxxxxxxxxxx'",
        "targetEntity": "Task",
        "userCriteria": "$User.ProfileId = '00exxxxxxxxxxxx'",
        "version": 1
    }
}
  • Use a POST request to create the restriction rule - POST /services/data/v52.0/tooling/sobjects/RestrictionRule
  • Copy your restriction rule definition into the request body.
  • Execute your request. Note the ID returned for the newly created restriction rule for later reference.
  • Retrieve and Update Information: Use the GET, PATCH, and DELETE methods to retrieve, update, and delete restriction rules.
  • More details on using Tooling API: https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_quickstart_tooling_methods.htm
  • For details on creation of the Restriction Rule Using the Metadata API, please refer - https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_quickstart_metadata_create.htm




Considerations:


  • As of Winter’ 22 release, Restriction rules are available for custom objects, contracts, events, tasks, time sheets, and time sheet entries. Restriction rules aren’t available for external objects.

  • We 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.

  • Restriction rules are applied to the following Salesforce features: List Views, Lookups, Related Lists, Reports, Search, SOQL, SOSL

  • Restriction rules don’t apply to users with the View All Data and Modify All Data permissions.

And many more..

      For details, please refer - https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_considerations.htm






Summary:


Let's sum it up:

  • Sharing rules open up access and Restriction Rules reduce access on top of Sharing Rules based on 2 criteria:
          User Criteria - decides users restricted from record access.
          Record Filter - Decides records that can be seen by these restricted users.
  • Not inherited from Parent to Child: that is creating a RR for an object i.e. suppose I create RR on Contract object, the access doesn't change for notes that are associated with affected Contract record.

  • As already mentioned, RR allows to set up access so that custom object, Time Sheet, TS Entries, Contract, Tasks, Events are completely private even for users with access to related Accounts which was not possible before.

  • Restriction Rule is a powerful tool using which we can now control child rceord which are controlled by parent permission.



Reference(s):

https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_about.htm
https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_restriction_rules.htm&type=5&release=234
https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_sharing_restriction_rules_beta.htm&type=5&release=232
https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule_create.htm&type=5
https://developer.salesforce.com/blogs/2021/05/control-access-to-sensitive-records-with-restriction-rules-now-in-beta
https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_considerations.htm
https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_examples.htm
https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_intro.htm

Comments

Post a Comment