Salesforce Basics: Restriction Rules, Scoping Rules & Implicit Sharing

💬 In plain words: Everything else in sharing only ADDS access. Restriction Rules are the one tool that SUBTRACTS. They filter which records a user can see even if sharing granted them. Scoping rules just change the default view, not real access. Implicit sharing is built-in glue (see the Account, see its child Cases).

📌 Example: Contractors log time in Tasks, but must not see employees' tasks. OWD change would hurt everyone — instead, place one Restriction Rule on the contractor permission set: 'you see only Tasks where OwnerId = you'. Everyone else remains unchanged.

🎬 Real-Life Example: The Contractor Who Saw Too Much

Hub contractors log in to update deliveries for their own hub. But role hierarchy and sharing rules keep granting them a wider view — other hubs, other cities.

The Old/Bad Way: Try to fix it with more sharing configuration. Hours of tweaking, no result. Because sharing can only ADD access. Nothing in OWD, roles, or sharing rules can take access away from someone who already has it.

Why this is bad: You are pushing on a door that only opens outward. The model is additive by design; fighting that with more grants makes the org harder to reason about, not tighter.

The New/Good Way:

1. Create a Restriction Rule on Delivery__c.
2. User criteria: the contractor permission set.
3. Record criteria: Hub__c equals the user's hub.
4. For those users, every non-matching record simply disappears — from lists, reports, lookups, and APIs.

The payoff: Sharing adds. Restriction Rules subtract — the only subtractor in the whole model. Reach for them when the problem is "they see too much", not "too little".

🧠 The only subtractor: Everything in sharing ADDS access. Restriction Rules are the one tool that SUBTRACTS. Say that line first.

Concept

Restriction Rules are the platform's only subtractive record-security tool.

• Per object, they filter which records a targeted set of users can SEE at all — in queries, list views, reports, and related lists — on top of whatever sharing already granted.
• Scoping Rules look similar, but they are UX, not security.
• They set the default scope a user sees, while the user can still reach everything sharing allows.
• Implicit sharing is built-in parent/child behavior on the CRM core.
• Read access to a child Case, Opportunity, or Contact confers read access to the parent Account.
• Account access can confer access to the children, depending on settings.
• You cannot turn it off, and it surprises people in security reviews.
• Restriction Rules connect back to OWD strategy. They let you keep a permissive OWD and still carve out a restricted subset.

🧭 360 Card — Restriction, Scoping & Implicit

Rule: Sharing adds. Restriction rules subtract. Scoping rules only change the default view.

Gain: A way to give one group less than everyone else, without touching OWD and resharing the whole org.

Price: Restriction rules are absolute. They hide records from reports, related lists, and even lookups. People report that as data loss.

Limits: Two active rules per object in Enterprise and Developer editions. Five in Performance and Unlimited. For any one user, only one restriction or scoping rule per object can be true. They work on custom objects, external objects, contracts, tasks, events, quotes, and time sheets. Not on Account, Contact, or Opportunity. Filters only, with no AND or OR. Implicit sharing is built in and cannot be switched off. Scoping rules change what is shown, not what is reachable.

Mirror — tightening OWD instead: Correct in principle. It also changes access for every user type at once, plus triggers a full recalculation.

Later: Document restriction rules next to the OWD settings. Otherwise the next architect debugs them as a bug, not a rule.

At volume: Implicit sharing is where surprise access usually comes from. It grows with every child record added under a parent.

⚠ INTERVIEW TRAP: Do not design one restriction rule per team. You get only 2 per object in Enterprise and Developer. The rule must be generic and driven dynamically by a user field.

Core Q&A

Q: Give a scenario where a Restriction Rule is the right tool rather than tightening OWD, and state its limits.

🎯 Say this first: Use them when one group must see LESS than everyone else. Restriction rules subtract.

A: Take contract staff who must see only their own Tasks in an org where Task visibility is otherwise broad.

• Flipping OWD would break every other user type and set off a massive resharing job.
• Instead, write one Restriction Rule targeting the users who hold the contractor permission set. Its recordFilter is OwnerId = $User.Id. It subtracts exactly their visibility and touches nobody else.
• State the limits: There is a small per-object cap on active rules (single digits).
• The filter syntax is strictly simple (no complex OR logic).
• The supported object list is restricted: Tasks, Events, Contracts, custom objects, and a defined set of standard objects.
• It affects reporting — records vanish from contractors' report results, which the business must sign off on.
• Bonus point: Restriction rules also apply to users who hold View All on the object. That is exactly why they exist.

Follow-ups (Scenario-Based)

Q1: A service agent can see an Account they were never shared. Sharing audit shows nothing on AccountShare. Where does the access come from?

A1: This is implicit parent sharing.

• The agent has access to a Case (or Opportunity/Contact) under that Account. That child access grants implicit Read on the parent Account.
• These grants do not show up as standard rows in a share-table audit because the platform maintains them internally.
• The reverse direction exists too: Account team or owner access flows down to child records depending on account settings.
• In a security review, you must document implicit sharing explicitly since you cannot disable it.
• If the parent Account must truly remain hidden, the child access itself must be redesigned.

Q2: Auditors demand that lab technicians see only assessments for their own lab, in an org where assessments are Public Read Only. What is the least-disruptive design?

A2: Put a Restriction Rule on the assessment object targeting the technician user type.

• Filter on the record's Lab__c matching the technician's lab, stamped on a custom field on their User record.
• OWD stays unchanged. Every other user type remains untouched.
• No resharing storm, no rule sprawl.
• Two trade-offs to flag to auditors: Technicians' reports and list views will now show only their own lab (the desired outcome), but you have spent one rule from a very limited budget per object.
• The lab-match design must be generic (driven by $User fields). Common mistake: Creating one rule per lab, which quickly hits system limits.

Q: Explain implicit sharing and where it bites a design.

🎯 Say this first: Access to an account quietly drags related access with it — in both directions.

A: It works both ways. Parent implicit sharing: seeing a contact, case, or opportunity grants read access to its parent account automatically. Child implicit sharing: the account owner gets access to child records governed by the role's child settings. It is built-in and cannot be turned off. A "Private accounts" design can still leak account names through child records if not properly mapped.

Q: How does this change for Experience Cloud users?

A: External users have no internal role hierarchy, so implicit sharing plus sharing sets handle access. A sharing set grants a portal user access to records related to their own account or contact. For cross-account partner visibility, use Share Groups and Super User Access. Always set external org-wide defaults (OWD) to Private first.

Q: What is the danger with restriction rules?

A: They are absolute. A bad restriction rule completely hides records from reports, related lists, and lookup fields — causing users to report it as data loss rather than a rule execution. Keep them few, test them per persona, and document them directly alongside your OWD settings so future architects understand how subtractive access is being applied.