Salesforce is known for its robust and flexible security model that helps admins and developers enforce data access policies at every level. Traditionally, we have controlled record-level access using mechanisms like Organization-Wide Defaults (OWD), Sharing Rules, and Role Hierarchy.

However, with the introduction of Restriction Rules, Salesforce has added a new dimension to its sharing model — one that focuses not on granting access, but on restricting it. Let’s explore what Restriction Rules are, how they work, and how they differ from other record-level access tools.


🧭 What Are Restriction Rules?

Restriction Rules are a newer feature introduced by Salesforce to narrow down the records a user can see, even if those records are accessible via other sharing mechanisms.

While OWD, Sharing Rules, and Role Hierarchy are used to open up access to more records, Restriction Rules are used to tighten that access based on certain criteria.

They apply primarily to:

  • List Views
  • Lookups
  • Search results
  • Reports (some limitations)
  • SOQL queries

🧱 Supported Objects

As of now, Restriction Rules are supported for:

  • Custom Objects
  • Standard Objects like Contracts, Assets, Cases, Events, Tasks, and TimeSheets

Always check Salesforce documentation for the latest supported objects.


🛠️ How Restriction Rules Work

Restriction Rules use a filter logic that you define. If a user does not meet the criteria defined in the rule, they won't see the record, even if they have access via role hierarchy or sharing rules.

Example:

User Criteria: Profile = 'Partner User'
Record Criteria: Account.Type = 'Partner'

In this case, a user with the 'Partner User' profile will only see accounts where the type is 'Partner'.


🔍 Where Are Restriction Rules Applied?

Restriction Rules primarily affect:

  • List views: Users won’t see restricted records in list views.
  • Lookups and search results: Records that don't match the restriction rule will be hidden.
  • Reports and Dashboards: Limited support; in many cases, restricted records won’t appear in standard reports.
  • SOQL queries: If a user runs a SOQL query from Apex or Developer Console, only allowed records are returned.

⚖️ Restriction Rules vs. OWD, Sharing Rules, and Role Hierarchy

Let’s break down how Restriction Rules compare to other access control mechanisms:

Feature Purpose Behavior Can Reduce Access? Use Case
OWD Set baseline access level (Public, Private, etc.) Grants minimal default access ❌ Set default visibility
Role Hierarchy Inherit access vertically Grants access upward ❌ Manager access to team records
Sharing Rules Open up access based on record ownership or criteria Grants access horizontally ❌ Share records with peers or groups
Restriction Rules Restrict record visibility based on criteria Narrows access even if access is granted by other means ✅ Hide sensitive data from certain users


⚠️ Important Considerations

  • Restriction Rules do not override field-level security (FLS) or object-level permissions.
  • Users can only see records that meet both the sharing model and the restriction rule criteria.
  • Only one restriction rule per object per user is evaluated — Salesforce does not support multiple active rules per user per object.
  • These rules do not apply to related records (e.g., they don’t prevent access to child records via parent lookup).

🚀 Real-World Use Case

Imagine you have a Partner Community where users are granted read access to all Opportunities. However, you want them to see only Opportunities related to their own accounts.

Even if Sharing Rules and OWD allow access, you can enforce this with a Restriction Rule like:

User.AccountId = Opportunity.AccountId

This ensures they only see Opportunities tied to their own Account.


🧩 When to Use Restriction Rules

Use Restriction Rules when you need:

  • To filter down visible records without changing your entire sharing model.
  • More granular control in external-facing applications (like Experience Cloud).
  • To enforce data visibility restrictions that aren’t achievable through roles or sharing.

📝 Final Thoughts

Restriction Rules fill a much-needed gap in the Salesforce security model — allowing negative permissioning (i.e., hiding data). They are particularly useful in scenarios where more open access models are needed for functionality, but you still want to enforce visibility boundaries for compliance or business logic.

As with all security tools, use them thoughtfully and test thoroughly in sandboxes before deploying to production.

Have you tried Restriction Rules in your Salesforce org? Share your experiences or questions in the comments below!