Skip to content
Namaste Salesforce Namaste Salesforce
Exit to track
Architect Roadmap

Restriction rules

Every other sharing tool grants access. Restriction rules subtract it — filtering what users can see within their access.

Architect Roadmap Article 1 min

Restriction rules

Nearly every mechanism in the sharing model is additive — OWD, hierarchy, and sharing rules only ever grant access. That makes one requirement historically hard: "this user has access to the object, but should see only a subset of the records they otherwise could." Restriction rules fill that gap by subtracting visibility, letting you filter the records a user or group of users can see within the access they already have.

A restriction rule is defined on an object and applies to specified users (by profile, role, permission set, or other criteria). It has a record filter that expresses which records those users are permitted to see. The effect is an intersection: a user sees a record only if their normal sharing grants access and the record matches the restriction rule's filter. Records that fail the filter simply disappear from that user's list views, reports, searches, and API results — they are filtered out rather than access-denied.

Visible to user = (records granted by sharing model)
                  INTERSECT
                  (records matching the restriction rule's filter)

Example: Contractors have Read on Case via a permission set,
         but a restriction rule limits them to
         Case.Origin = 'Partner Portal' only.
         -> They see partner cases only, never internal ones.

Restriction rules are ideal for scenarios like limiting contractors to non-confidential records, showing an integration user only the records relevant to its job, or scoping a support tier to a category of cases — all without restructuring OWDs or building elaborate sharing that you would then have to claw back. They apply to both custom objects and a growing set of standard objects, with per-object and per-user-type limits, so check current constraints when designing.

The architectural value is expressing "grant broadly, then narrow precisely" cleanly, instead of contorting the additive model. As an exercise, take a requirement where a group has object access but must be blocked from a sensitive record category, and write the restriction rule filter that scopes them down. With the sharing domain complete, the roadmap's final section moves to how Salesforce integrates with other systems at an architectural level.

Advertise with us · 728×90