It Looked Like a Sharing Bug. It Was a Restriction Rule Nobody Remembered Adding.

A contract-approval report at a finance-sector org started showing fewer records to two reviewers than it had the week before. Nobody had touched a sharing rule. Nobody had restructured the role hierarchy. The org-wide default on Contract hadn't moved in over a year. The instinctive diagnosis for a ticket like this - 'sharing recalculation broke again' - is worth questioning before anyone reruns a recalculation that was never going to fix anything, the way a Salesforce Health & Roadmap review starts by checking what's actually filtering access rather than assuming which layer is at fault.

For most of the platform's history, that instinct has usually been close enough - a stale sharing rule, a role-hierarchy move that hadn't finished recalculating, an org-wide default nobody documented. It's wrong often enough now to matter, because there's a newer layer sitting on top of all of it that most admins have never had a reason to open: restriction rules. They don't show up on the Sharing Settings page, they don't appear in an audit trail the way a sharing-rule edit does, and they don't throw an error anywhere a report can surface it - they quietly remove records a user would otherwise see, which is exactly what they're built to do, just not where anyone thinks to look first. A sharing model nobody has revisited in years is the familiar version of this problem; a restriction rule nobody remembers adding is the newer one.

What the ticket looked like

The triage followed the usual order, because it's the right order for almost every other sharing complaint: check the sharing rules on Contract, confirm nothing had changed there; check the two reviewers' position in the role hierarchy, confirm nothing had moved; recalculate sharing anyway, in case something hadn't finished propagating. None of it explained anything, because none of it was the right layer. The gap wasn't intermittent and it wasn't spread across random users - it was the same two reviewers, missing the same category of record, on every view: the report, the Contract list view, even global search. That consistency is unusual for a genuine sharing bug, and it's exactly what should have redirected the search sooner than it did.

What the investigation actually found

Setup → Restriction Rules on Contract showed one active rule, created months earlier by a different admin, scoped to limit visibility into contracts flagged with a confidential-terms indicator to a smaller review group. Nobody who was now troubleshooting the report had added it, and nothing in the standard sharing audit path surfaces it. That's the mechanical difference worth sitting with: every layer in the ordinary sharing stack - org-wide defaults, role hierarchy, sharing rules, manual or Apex sharing - has to actively grant access for a user to see a record. A restriction rule is the one layer that takes access away after everything else has already granted it. And per Salesforce's own documentation, it doesn't just apply to record access - it's enforced across list views, related lists, search, SOQL, SOSL, and reports, which is exactly why the missing records showed up everywhere at once instead of in one isolated place.

The underlying issue: a layer built to be invisible

Restriction rules were built for one job: letting a security-conscious admin lock down a narrow slice of sensitive data without touching the sharing model everyone else depends on. That's a reasonable feature, and the design choice that makes it good at that job is the same one that makes it hard to troubleshoot - it lives in its own corner of Setup, it doesn't get surfaced in a sharing-rule audit, and most teams don't yet have a habit of checking for one, because most teams have never needed to add one. Current limits keep the blast radius small on purpose: up to two active restriction rules per object on Enterprise and Developer editions, up to five on Performance and Unlimited - this isn't a mechanism meant to run an org's entire security model, only to carve out specific, narrow exceptions. It's also scoped to a defined list of objects: custom objects, external objects, and a specific set of standard ones - Contract, Event, Quote, Task, Time Sheet, and Time Sheet Entry. That object list rules a lot of 'the report is wrong' tickets out immediately: if the object in question is Account, Opportunity, Lead, or Case, a restriction rule isn't the cause. Those run on a related but different mechanism - scoping rules - which only changes what shows by default and never actually removes access the way a restriction rule does. Confusing the two is its own common mistake (more on that below).

What actually fixed it

1. Confirm the object first. If the report in question runs on Account, Opportunity, Lead, or Case, a restriction rule isn't the cause - rule it out immediately and look at scoping rules or the ordinary sharing stack instead.
2. Check Setup → Restriction Rules on the object before recalculating anything. It takes under a minute and rules out, or confirms, the one layer a sharing-rule audit won't show.
3. If a restriction rule is the cause, treat it as a finding, not a bug to quietly disable. Someone added it for a real security reason; the fix is documenting what it does and why, not removing it to make the report match what it used to show.
4. Add 'active restriction rules on this object' to the standard checklist for any 'the report or list view is missing records' ticket, ahead of 'recalculate sharing' - a five-minute check that rules out a growing category of tickets the sharing stack alone doesn't explain.

The takeaway

A report that stops matching what everyone remembers isn't always evidence something broke. Sometimes it's evidence something is working exactly as configured, by a layer most admins have never had a reason to check. That's a bigger shift than one feature: every access-control mechanism Salesforce adds on top of the original sharing model - restriction rules, scoping rules, and whatever ships next - creates one more place a 'the numbers are wrong' ticket can genuinely originate from, without being a bug anywhere. The fix isn't memorising every mechanism's documentation. It's building a troubleshooting order - object type first, then restriction rules, then scoping rules, then the ordinary sharing stack - so 'recalculate sharing' stops being step one by default, on tickets where it's often not even the right building.

A few questions worth asking before the next recalculation

Does every 'the report is missing records' ticket mean a restriction rule?

No - treating every visibility complaint as a restriction-rule hunt wastes time in the other direction. Restriction rules only apply to custom objects, external objects, and a specific list of standard objects (Contract, Event, Quote, Task, Time Sheet, Time Sheet Entry). If the report runs on Account, Opportunity, Lead, or Case, a restriction rule isn't the cause - look at scoping rules or the ordinary sharing stack instead.

What's the actual difference between a restriction rule and a scoping rule?

A restriction rule removes access a user would otherwise have, and it's enforced everywhere - reports, list views, related lists, search, SOQL, and SOSL. A scoping rule only narrows what shows by default in a list view or similar context; the underlying access never changes, and a user who adjusts their filters can still see everything they were always entitled to. Mistaking one for the other is its own common troubleshooting error - a scoping rule will never explain a record missing from a report with no default filter applied.

How many restriction rules can one object actually have?

Up to two active restriction rules per object on Enterprise and Developer editions, and up to five on Performance and Unlimited editions, per Salesforce's current documentation. That cap is a useful sanity check on its own: a team reaching for more than that is probably using restriction rules for a job they weren't built for, and the access model likely needs a broader rework instead.

The bottom line

'Recalculate sharing' is still a reasonable first move for most visibility tickets, but it's no longer a safe assumption that it's the right one. A one-minute check of Setup → Restriction Rules on the object in question, run before anything else, now belongs ahead of it - on a custom object or a Contract, Event, Quote, Task, or Time Sheet, it can save hours spent recalculating a sharing model that was never actually the problem. If an org's access model has accumulated enough layers that nobody can predict what a given report will show, our senior architects can walk through what's actually controlling visibility before the next ticket like this one lands - talk to us if that sounds familiar, or start with our services overview to see where that kind of review fits.