3.6 Data Visibility, Reporting, and Analytics Security

Reports Do Not Ignore Security

Reports are not a shortcut around Salesforce security. A user normally needs access to the report folder, the report type, the underlying object, the fields included, and the records returned by sharing and filters. If any layer blocks access, the user may be unable to run the report, may see missing columns, may see fewer rows than a manager, or may see a dashboard total that differs from the source report they can run.

Start with the exact symptom. Cannot open report means folder access, report permission, or report type availability may be the issue. Can open report but rows are missing means record access, filters, role hierarchy, sharing, report type joins, or row limits may be involved. Can open report but a field is missing means FLS or report type layout may be involved. Can see a dashboard but not drill into all records means running user and viewer permissions may differ.

Folder Access Is Artifact Access

Report and dashboard folders control the analytics assets: who can view, edit, and manage the reports and dashboards stored there. Folder access does not grant the underlying object, field, or record access for ordinary reports. A user can have access to a folder and still see no records if the report returns records they cannot access. A user can have record access but fail to open a report if the folder is not shared with them.

This distinction is a favorite exam pattern. If a sales manager cannot find a dashboard, check folder sharing. If the manager opens the dashboard but the component total is lower than expected, check the running user, report filters, report type, and record access. If a field column is not available, check FLS and report type configuration rather than OWD first.

Dashboard Running User And Dynamic Dashboards

Dashboards can run in a specified user context or, where configured, as the logged-in viewer for dynamic behavior. A fixed running user can display totals based on that user's access, which may be broader or narrower than the viewer's own access. This can be useful for executive reporting but must be governed because it may show aggregate results beyond a viewer's direct record visibility.

Dynamic dashboards let viewers see dashboard data according to their own access, which is often better for team dashboards where each manager should see their territory or role-based data. Limits and feature availability can vary by edition and org settings, so administrators should verify what the org supports. The exam-level concept is the context choice: fixed running user versus viewer-context dashboard behavior.

Scenario: A rep runs a pipeline report and sees ten opportunities. A dashboard component using the same report shows a total based on the VP of Sales as running user. The dashboard may show a broader total because the VP can see more records. That does not mean the rep has direct access to those records. Drilling into details may be limited by the rep's access and dashboard settings.

Report Types, Filters, And Sharing

Custom report types define which objects and relationships are reportable together and whether child records are required or optional. If an Account with no Opportunities is missing from an Accounts with Opportunities report, the issue may be report type join behavior rather than sharing. If a Case report filters Owner equals Current User, managers may not see subordinate cases even though their role hierarchy grants access, because the filter is too narrow.

Filters are often the simplest cause of missing rows. Date ranges, role filters, ownership filters, status filters, cross filters, and relative date values can exclude records. An admin should inspect filters before changing security. However, if filters are correct and the row count differs by user, sharing is a strong suspect.

FLS also matters in analytics. If a field is hidden by FLS, the user should not rely on a report to see it. If a report filter uses a field the user cannot see, behavior can be confusing and should be tested carefully with the target user profile or permission set. Sensitive fields need FLS protection first.

Analytics Troubleshooting Workflow

Use this sequence for report and dashboard tickets:

1. Identify whether the problem is opening the artifact, seeing rows, seeing fields, editing the report, subscribing, exporting, or dashboard totals.
2. Check folder access and report or dashboard permissions.
3. Check object Read permission and whether the report type is available.
4. Check FLS for displayed, grouped, filtered, or summarized fields.
5. Check report type relationships and whether child records are required.
6. Check report filters, including date range and owner or role filters.
7. Check record access through OWD, role hierarchy, sharing rules, teams, territories, manual shares, and broad permissions.
8. For dashboards, check fixed running user versus dynamic viewer context.
9. Retest with the affected user and compare to a known control user.

This workflow keeps the admin from treating every analytics issue as a sharing issue. It also prevents the opposite mistake: making a report folder visible to everyone while the real problem is that the running user reveals an executive aggregate to the wrong audience.

Data Export And Security Judgment

Reporting permissions can include capabilities such as creating reports, exporting reports, subscribing, or managing folders. Export rights deserve special care because data leaves the UI. A user who can export a report with sensitive fields can store those values outside Salesforce controls. Assign export permission by job need and pair it with FLS, record access, and company data handling policy.

For Agentforce or analytics features that ground answers in Salesforce data, admins should apply the same visibility mindset. The feature should not become a workaround around object, field, or record security. Test with realistic users and verify that generated responses or analytics summaries do not reveal data the user should not access.

Exam Traps

Do not assume folder sharing grants row visibility. Do not assume private OWD hides report folders. Do not assume the report builder shows every field to every user. Do not assume a dashboard total equals the viewer's personal record access. Always separate the artifact, the report design, and the data visibility model.

A practical study drill is to create one private object scenario in a Playground, two users in different roles, and one report folder. Run the same report as each user, then change only folder access, only sharing, and only FLS. Watching which symptom changes makes the exam logic much easier.