Salesforce Restriction Rule

Salesforce Restriction Rule

The restriction rule allows us to restrict the sensitive data on the top of the OWD, sharing settings, and manual sharing. It basically filters the record. When a restriction rule is applied to a user, the records that the user is granted access to via org-wide defaults, sharing rules, and other sharing mechanisms are filtered by criteria that you specify.

Note: Before creating restriction rules, we recommend that you turn off Salesforce Classic for your Org. Salesforce can’t guarantee that restriction rules work as intended for end users who are in the Salesforce Classic experience.

Now the question is, in how many areas is it available? Below is the list

1. Task
2. Custom Object
3. External object
4. Event
5. Contract

Restriction rules are applied to the following Salesforce features:

• List Views
• Lookups
• Related Lists
• Reports
• Search
• SOQL
• SOSL

Creation of Restriction Rule

There are two criteria

1. User criteria: Under User Criteria, select which users this restriction rule applies to
2. Record criteria: Under Record Criteria, select which records the specified users are allowed to see. For the Field value, you can reference another object’s field using dot notation.

Salesforce Restriction Rule Creation

Restriction Rule Considerations (Reference from Help)

• Users can see their subordinates’ events in calendars even if the users have an active restriction rule applied.
• If a user creates an event or a task record using the Chatter publisher, the record name is visible in the related Chatter post. Restriction rules don’t restrict visibility to these record names.
• Users can’t clone records that have a lookup to a record that they can’t see due to a restriction rule. For example, you have a restriction rule that prevents a user from seeing a specific contract record, and the user tries to clone an order record that has a lookup to the contract record. The user gets an error, preventing the clone operation from succeeding.
• Restriction rules aren’t applied for code executed in System Mode.
• Restriction rules don’t apply to users with the View All, Modify All, View All Data, and Modify All Data permissions. Users with these permissions can test to see the impact that restriction rules have on performance, especially with large data volumes. See Performance Considerations for more.
• A user with a restriction rule applied might not find all possible matching results when searching for a record. For performance reasons, search crowding applies limits to the number of search results. The record the user is looking for can fall outside those limits.
• The UserRecordAccess object doesn’t consider whether a user’s access is blocked due to a restriction rule. If a user’s access is blocked even though query results state that they should have access, check to see if a restriction rule on the object prevents the user’s access.
• 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.
• Create only one restriction or scoping rule per object per user. In other words, for a given object, only one restriction or scoping rule at most can have the User Criteria field evaluated to true for a given user.
• Creating a restriction rule for an object doesn’t automatically restrict access to its child objects. For example, if you create a restriction rule for the Contract object, the access doesn’t change for notes that are associated with the affected contract records. To secure these child objects, you must use other sharing mechanisms.
• We support these data types in the User Criteria and Record Criteria fields: boolean, date, DateTime, double, int, reference, string, time, single picklist
• NOTE Comma-separated ID or string values are supported in the Record Criteria field.
• Having two consecutive underscores in the FullName field isn’t supported.
• The use of AND and OR operators isn’t supported.
• The use of formulas isn’t supported.
• Don’t create rules on Event.IsGroupEvent, which indicates whether the event has invitees.
• You can use a change set or unlocked package to move restriction rules from one org to another.
• Some IDs are specific to your Salesforce org, such as role, record type, or profile IDs. If you include these IDs in your User Criteria or Record Criteria fields, keep this consideration in mind when deploying rules between sandboxes or to a production org. You must modify these IDs in the target org if the restriction rules were originally created somewhere else.
• When a field that you’re trying to reference is polymorphic, specify the object type in your syntax. For example, the Owner field on an Event object can contain a user or a queue. So it’s necessary to specify Owner:User in the record criteria syntax when the criteria should allow only users.