Restriction Rules Developer Guide

About This Guide
Restriction Rules
Quick Start: Control Which Tasks the Sales Team Can Access
Considerations
Example Scenarios
Tooling API Reference
Metadata API Reference
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Considerations

Keep these considerations and limitations in mind while using restriction rules.
Available in: Lightning Experience in Enterprise, Performance, Unlimited, and Developer Editions

Available Objects

  • Before creating restriction rules, turn off Salesforce Classic for your org. Find instructions at Turn Off Salesforce Classic for Your Org.
  • Restriction rules are available for custom objects, contracts, events, tasks, time sheets, and time sheet entries. Restriction rules aren’t available for external objects.
  • In calendars, if the Show Details access level is selected, users can see the subject of all events, regardless of the restriction rules created. For more information, see Share Your Calendar in Lightning Experience in Salesforce Help.

Applicable Features

  • Restriction rules are applied to the following Salesforce features:
    • List Views
    • Lookups
    • Related Lists
    • Reports
    • Search
    • SOQL
    • SOSL
  • Restriction rules support custom picklist values in user criteria. If you delete a custom picklist value used in a restriction rule, the rule no longer works as intended.
  • Use the Activity Timeline instead of Open Activities or Activity History. If you use Open Activities and Activity History related lists, create rules on task or event objects using fields that are only available on the OpenActivity and ActivityHistory objects.
  • If you use Open Activities and Activity History related lists, when restriction rules are applied, it’s possible that fewer than 50 records are displayed when more activities exist that the user has access to. This behavior occurs because these lists display at most 50 records, and restriction rules are applied after. This behavior is related to the known issue, Limit of Fifty Records Visible in Related List View.
  • Users can still see records they previously had access to in the search box shortcuts list or in the Recently Viewed list view after restriction rules are applied. When users click the record name, they can't access the record and get an error.
  • 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 Data and Modify All Data permissions.
  • 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. Learn how to adjust your searches for the best results at How Search Crowding Affects Search Results.

Creating Restriction Rules

  • 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 rule per object per user. In other words, for a given object, only one restriction rule at most should have the userCriteria field evaluate 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 recommend that you don’t edit the targetEntity field after the restriction rule is created. Instead, delete the existing rule and create a new restriction rule with the correct values.
  • 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 recordFilter syntax when the filter allows only users.
  • You can reference another object’s field using dot notation in the recordFilter field. You can use only one “dot” (one lookup level from the targetEntity). For example, Owner.UserRoleId. See Allow Users to See Only Records Owned by Same Role and Allow Users to See Only Records Owned by Same Profile for examples.
  • We support these data types in the recordFilter and userCriteria fields:
    • boolean
    • date
    • dateTime
    • double
    • int
    • reference
    • string
    • time
    • single picklist (user criteria only)
  • Having two consecutive underscores in the FullName field isn’t supported.
  • Restriction rules support only the EQUALS operator. The AND, OR, or any other operators aren’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.
  • 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. Keep this consideration in mind if deploying rules between sandboxes or to a production org.