The same report shows different numbers to different people because reports respect record access, and access differs by user. Before you suspect the report, confirm it: have both users open the report and compare the record counts, then work down sharing, role hierarchy, the report’s own filters, and finally the dashboard running user. It is almost never the report definition.
Check this first
Have both users run the report and note the row count and the total. If the counts differ, it is access. If the counts match and the totals differ, it is field-level security or currency. Those are two completely different investigations and five minutes here saves an hour.
Cause 1: record-level access
A report returns the records the running user can see. A rep sees their own opportunities. Their manager sees the team’s. An admin with View All Data sees everything.
This is correct behaviour and it is the cause roughly three times out of four. What makes it confusing is that nothing in the report says so — there is no banner explaining that 400 rows were filtered out by sharing.
To confirm, compare against the underlying data as an administrator:
SELECT COUNT(Id) FROM Opportunity WHERE CloseDate = THIS_QUARTERIf the admin count is 1,200, the manager sees 340 and the rep sees 45, nothing is broken. Work down the access layers if the numbers are not what the business expects.
Cause 2: the role hierarchy is not the org chart
Managers see their subordinates’ records through the role hierarchy, not through their job title. A newly promoted manager whose role was never changed sees what they saw as a rep.
Check the role, not the profile:
SELECT Id, Name, UserRole.Name, Profile.Name
FROM User
WHERE Id IN ('005XXXXXXXXXXXXXXX', '005YYYYYYYYYYYYYYY')This one is worth checking early because it is common and the fix is a single field change.
Cause 3: “My” filters baked into the report
The report’s scope filter (My Opportunities, My Team’s Opportunities, All Opportunities) is relative to whoever runs it. A report saved with “My Team’s” shows each viewer a different team, by design.
Open the report, check the scope, and check whether any filter uses a relative value. Filters on OwnerId = $User.Id, on the current user’s role, or on “My” anything are all viewer-relative.
Cause 4: field-level security changes the totals
If a user cannot see a field, it does not appear for them — and a summary over it is affected. Two users with identical record access can see different totals because one cannot read Amount.
This is the case where row counts match and totals do not, which is why the first check in this article is worth doing.
Cause 5: currency, in a multi-currency org
Amounts are converted to the running user’s personal currency using the current conversion rates. Two users with different personal currencies see different numbers for the same records, and both are right.
Dated exchange rates complicate this further: with them enabled, conversion uses the rate effective on the record’s date rather than today’s, so historical totals shift when somebody adds a rate. If a report “changed” without anybody editing it, check whether an exchange rate was added.
Cause 6: the dashboard running user
A dashboard does not run as the viewer by default. It runs as its configured running user, so every viewer sees that person’s numbers — which is why a dashboard and the report it is built on can disagree for the same person.
Dynamic dashboards run as the viewer instead. The tradeoff is real: dynamic dashboards cannot be scheduled for refresh in the same way and there is a cap on how many an org can have, so they are not a blanket answer.
When someone says “the dashboard is wrong but the report is right”, this is nearly always it.
Cause 7: time zones
Date filters are evaluated in the running user’s time zone. A report filtered to “Today” covers a different 24 hours for a user in Sydney than one in London, so records near midnight fall in or out depending on who is looking.
For reports that must be comparable across regions, filter on an explicit date range rather than a relative one.
A procedure
- Both users run it. Compare row count and total.
- Counts differ → access. Check role, then sharing, then the report scope filter.
- Counts match, totals differ → field-level security, or currency.
- It is a dashboard → check the running user before anything else.
- Only then look at the report definition.
Preventing the question
- Name reports for their scope. “My Team’s Open Pipeline” tells the viewer what to expect; “Pipeline Report” does not.
- Put the running user in the dashboard title where it matters, so the number is attributable.
- Use absolute date ranges in anything compared across regions or quoted in a meeting.
- Agree one source of truth per metric. Most “the numbers disagree” arguments are two reports with slightly different filters, both saved by people who were right at the time.
Frequently asked
Can I make a report show all records regardless of the viewer?
Only by giving the viewer access, or by running it as someone who has it: a dashboard with a running user, or a scheduled report sent from a user with broad access. Reports have no privileged mode of their own.
Does a report respect field-level security?
Yes. Fields the user cannot see are not available to add and are excluded from summaries for that user.
Why does my scheduled report differ from what I see?
A scheduled report runs as the user who scheduled it. The recipient sees that person’s access, not their own.
Do report folders affect the numbers?
Folder access controls who can open the report, not which records it returns. Those are separate, and conflating them sends people down the wrong path.
Why did the total change when nobody edited the report?
Records moved in or out of the filter, sharing changed, or an exchange rate was added in a multi-currency org. The last one is the least obvious and the most likely if the shift is uniform.
Reference: Reports and Dashboards, Dashboard Running User and Multiple Currencies, Salesforce Help.
