When two users open the same Salesforce report and see different fields, the cause is almost always field-level security: if a field is hidden from a user's profile and permission sets, it disappears from that user's report columns, filters, and results while a colleague with access sees it normally. The other usual suspects are the report type (which defines the universe of fields anyone can add), record type and page layout assignments (which change what users see on records, and which picklist values exist), and sharing settings (which change which rows appear, not which fields). A 15-minute permission comparison usually finds the gap. This matters because report discrepancies erode trust in the CRM faster than almost anything else — the fix is usually a permission correction, not a report rebuild.
Four layers decide what any given user sees, and confusing them is how troubleshooting goes in circles:
When a user says "the report looks wrong," the first diagnostic question is whether fields are missing or records are missing. Those are different layers with different fixes.
A subtler version of the problem: a field that is visible in reports shows up blank for every user. Salesforce's own troubleshooting guidance points to a classic cause — the field's accessibility was set to Hidden at some point, which also removed it from page layouts. Users couldn't see the field on records, so they never entered data into it. The report column works fine; there's simply nothing to show.
The fix is a sequence, not a toggle: make the field visible again via field-level security, add it back to the object's page layouts, then backfill the missing values. Until the data-entry gap is closed, the report stays empty no matter how the report is configured.
Because FLS is evaluated per user at run time. Salesforce reports don't snapshot a field list — every run checks the running user's permissions. So when one user's profile grants access to a field and another's doesn't, the same saved report renders differently for each of them.
This is the scenario that surfaces during permission cleanup: an admin updates a user's profile or permission sets, and suddenly fields that were "broken" appear in the user's reports — nothing about the report changed. It's also why the reverse happens after an org tightens security: a field that was quietly removed from a permission set disappears from someone's favorite report, and the report gets blamed.
To pinpoint the gap, open the field in Setup and use the Field Accessibility viewer: it shows, per profile, whether the field is visible and why (profile setting, permission set, or both). Comparing the two users' profiles and permission sets against that view almost always names the difference.
Record types are assigned through profiles and permission sets, exactly like field permissions. A user whose profile includes only some of an object's record types will see different page layouts, different picklist values, and different create options than a user with the full set — on the same object, in the same org.
When a team reports "the dropdown has different options for me," that's usually record type assignment (which picklist values are available per record type) or a picklist restriction, not a report problem at all. Check the user's profile and permission sets against the object's record type assignments first.
Then you're in sharing territory. Salesforce help documentation on differing report results points to record-level access: role hierarchy position, sharing rules, account teams, territory assignments, and report filters like "My opportunities" versus "All opportunities" all change which rows a user sees. A dashboard can add another twist — dashboards can run as a specific user, so viewers see that user's data access, not their own.
One more quiet culprit: report folder sharing. If the "same report" turns out to be two copies in different folders, the copies can drift apart as people edit them. Compare report API names before comparing permissions.
| Symptom | Most likely cause | Where to fix it |
|---|---|---|
| A field column is missing for one user, present for others | Field-level security hides the field from that user | Setup → field → Field Accessibility; adjust profile or permission set |
| A field can't be added by anyone, including admins | The report type doesn't include the field | Edit the custom report type's field layout, or use a report type that includes it |
| A field column exists but is blank for everyone | Field was hidden from layouts, so data was never entered | Restore FLS + page layout placement, then backfill values |
| Different picklist values or page layouts per user | Record type assignments differ by profile/permission set | Setup → object → Record Types → assignments |
| Same report, different record counts or totals | Sharing model, role hierarchy, or record-scope filters | Compare "My/All" filters; review sharing settings and roles |
| Dashboard differs from the underlying report | Dashboard running user differs from the viewer | Dashboard properties → "View dashboard as" |
Recurring "the report looks different" tickets are a symptom of permission sprawl — too many profiles, inconsistent permission sets, fields added over years without a governance pass. The durable fix is consolidation: move permissions off profiles and onto permission sets organized by job function, so field access is deliberate and auditable. (A good starting framework is in our post on moving from profiles to permission sets.) Pair that with a quarterly field-access review on your most-reported objects, and document which fields are load-bearing for key reports so nobody removes access by accident.
Vantage Point designs and cleans up Salesforce permission models as part of Salesforce implementations — field-level security, record types, and report architecture that hold up as teams grow. For orgs that want this maintained continuously, managed services cover exactly this kind of permission-and-reporting hygiene, and advisory engagements help teams adopt the governance habits that prevent the next discrepancy.
Vantage Point is a Salesforce and HubSpot Solutions Partner and is employee-owned. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Yes. Reports evaluate the running user's field-level security every time they run, so a hidden field is unavailable as a column or filter and never shows values for that user. Granting access to the field on the user's profile or a permission set restores it in reports immediately — no report edits needed.
Because page layouts and report types are separate configurations. The report type defines which fields anyone can use in that report, so a field can be perfectly visible on records yet absent from the report type's field list. Edit the custom report type's field layout (or choose a report type that includes the field) to make it available.
No. Roles control record-level visibility — which rows a user can see through the role hierarchy — not field visibility. Field access is governed by field-level security on profiles and permission sets. If a field is missing for a user, look at FLS, not the role hierarchy.
Record types are assigned per profile and per permission set, so users with different permission assignments legitimately see different record types, page layouts, and picklist values on the same object. Compare the users' profile and permission-set record type assignments in Setup to find the difference.
Reports respect record sharing, so users with different roles, territories, or sharing-rule coverage see different rows and therefore different totals. Also check record-scope filters like "My opportunities" versus "All opportunities," which personalize results even when permissions are identical.
Where the org's login-access policies allow it, administrators can use "Login As" to run the report as that user and observe the exact fields and records they get. Combine that with the Field Accessibility viewer in Setup — which explains per profile why a field is hidden — and most discrepancies are diagnosed in minutes.