Scoping Rules (Beta) Developer Guide

About This Guide (Beta)
Scoping Rules (Beta)
Quick Start: One Associate Supports Multiple Advisors (Beta)
Considerations for Scoping Rules (Beta)
Example Scenarios (Beta)
Tooling API Reference (Beta)
Metadata API Reference (Beta)
PDF

Newer Version Available

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

Considerations for Scoping Rules (Beta)

Familiarize yourself with these considerations for using scoping rules.
Available in: Lightning Experience in Performance and Unlimited Editions

Search Considerations

  • Regardless of the scope, users can still see records that they previously viewed in the search box shortcuts list or in the Recently Viewed list view.
  • A user with a scoping 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 that the user is looking for can fall outside those limits. See the Welcome to Salesforce Search article for more tips.

Creating Scoping Rules

  • You can create up to five scoping rules per object.
  • Create only one scoping rule per object per user. For a given object, only one scoping rule’s userCriteria field can evaluate to true for a given user.
  • Creating a scoping rule for an object impacts only that object and doesn’t affect child objects.
  • 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.
  • These data types are supported in the recordFilter and userCriteria fields.
    • boolean
    • date (yyyy-MM-dd)
    • dateTime (yyyy-MM-dd HH:mm:ss)
    • double
    • int
    • reference
    • string
    • time
  • Having two consecutive underscores in the FullName field isn’t supported.
  • Unless you use SOQL, scoping rules support only the EQUALS operator. The AND and OR operators aren’t supported.
  • Don't create rules on Event.IsGroupEvent, which indicates whether the Event has invitees.
  • If you include an ID in your recordFilter or userCriteria field that is specific to your Salesforce org (such as a role, record type, or profile ID), you must modify the ID in the target org if it’s different from the org where the scoping rule was originally created. Keep this consideration in mind when deploying rules between sandboxes or to a production org.
  • For list views and reports, you can apply the scope through Metadata API (using the filterScope field on the ListView type and the scope field on the Report type “scope”).
  • When using the SOQL operator in the record criteria, the SELECT statement, including nested SELECT statements, must include USING SCOPE EVERYTHING. USING SCOPE EVERYTHING is the only valid scope clause syntax for scoping rules.
  • You can use a change set to move scoping rules from one org to another.

Modifying Scoping Rules

  • We recommend not editing the targetEntity field after a scoping rule is created. Instead, delete the rule and create another one with the correct values.
  • Deleting custom fields that are referenced in scoping rules results in an error.
  • To disable a scoping rule, first delete the list views and reports that have Filter by scope selected. After a scoping rule is disabled, the list views and reports aren't functional nor modifiable.
  • The scoping rule userCriteria field supports custom permissions. If you delete the custom permission, the scoping rules that use the custom permissions don’t work.