Considerations for Scoping Rules

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. Learn how to adjust your searches for the best results at How Search Crowding Affects Search Results.
• Salesforce can apply throttling or deactivate scoping rules that cause performance or other issues.

Creating Scoping Rules

Your edition affects how many active rules you can have.

• Create up to two active scoping rules per object in Developer editions.
• Create up to five active scoping rules per object in Performance and Unlimited editions.
• 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
  • single picklist (userCriteria only)
• Using two consecutive underscores in the FullName field isn’t supported.
• Don't create rules on Event.IsGroupEvent, which indicates whether the event has invitees.
• 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.
• 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”).
• Unless you use SOQL, scoping rules support only the EQUALS operator. The AND and OR operators aren’t supported.
• 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.
• The SOQL operator doesn't support $User syntax except for $User.Id. Dynamic queries within the SOQL operator aren't supported, including on other user object fields.

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

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.
• 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.
• Scoping rules support custom picklist values in user criteria. If you delete a custom picklist value used in a scoping rule, the rule no longer works as intended.

Accounts, Contacts, and Person Accounts

• Scoping rules don't support IsPersonAccount fields on the account object. When setting a scoping rule, don't use IsPersonAccount fields such as PersonDepartment or PersonLeadSource in record criteria. Find a list of IsPersonAccount fields on the Account page.
• An error can result if you navigate to a person account detail page from a Contacts list view. To navigate to a person account detail page when there's a scoping rule on the account object, use an Accounts list view such as All Accounts.
• In related lists, all associated records that a user can access are visible, regardless of scope, except in the contact role related list. When a scoping rule is applied on the contact object, scope is applied to the contact role related list that appears on account, opportunity, case, and contract records. So it’s possible that users, such as members of a sales team, will see a filtered set of contact roles without knowing that the list is filtered.
• When an org uses duplicate rules to prevent creating duplicate records, scoping rules limit the potential duplicates that are shown, even when Bypass sharing rules is turned on. Duplicate records are limited by the scope set in the scoping rule.