6.6 Analytics Security, Visibility, and Executive Reporting

The layers of analytics security

Salesforce reporting security starts before the report builder opens. A user needs access to the object, the fields, the records, and the folder that contains the report or dashboard. They also need functional permissions such as Run Reports, Create and Customize Reports, Report Builder, Export Reports, Subscribe to Reports, Manage Public Reports, or Manage Dashboards in Public Folders depending on the task. A user who lacks object access will not fix the issue by receiving a report link. A user who lacks field-level access should not see that field just because it is on a report.

Record visibility comes from organization-wide defaults, role hierarchy, sharing rules, teams, territories, manual sharing, queues, account relationships, and broad permissions such as View All or View All Data. Reports respect the accessible rows for the running user of the report. Dashboards add another layer because a specified running user can summarize data using that user's access. That is useful for executive reporting, but it must be governed so sensitive aggregate information is not exposed casually.

Executive reporting also requires definition control. A KPI such as net new pipeline can mean created date this quarter, close date this quarter, stage not closed, forecast category included, or amount converted to corporate currency. If each region uses a different report, leadership will argue about definitions instead of decisions. Admins should capture KPI definitions, source reports, filters, currency handling, fiscal calendar assumptions, and owner of each metric.

A report that is technically correct can still be unsafe. Exported CSV files may contain personal data, regulated information, or competitive sales details. Once data leaves Salesforce, Salesforce sharing no longer protects it. Admins should grant export permissions deliberately, classify sensitive fields, consider data loss prevention processes outside Salesforce, and train users not to email uncontrolled spreadsheets when a secured report subscription or dashboard would be better.

Visibility troubleshooting and AI-era reporting

When a stakeholder says a report is wrong, avoid guessing. Use a structured visibility path. First, run the report as yourself and capture the total. Then inspect the report type, filters, filter logic, date field, and scope. Next, log in as or use approved troubleshooting tools for a representative user if policy allows, or compare with a user who has similar permissions. Check object permissions, field-level security, record sharing, role hierarchy, territories, and folder access. For dashboards, check the running user and refresh time.

Troubleshooting workflow:

1. Confirm the business definition of the number being disputed.
2. Check source report type, filters, date fields, grouping, and row count.
3. Verify the viewer's object, field, record, and folder access.
4. Check dashboard running user, dynamic setting, filters, and last refresh time.
5. Compare a known record that should appear with one that should not appear.
6. Document whether the issue is data quality, security, report design, or timing.

Agentforce and AI-assisted experiences do not remove these rules. Admin-level Agentforce work focuses on use cases, permissions, prompt and agent configuration boundaries, testing, trust, deployment, monitoring, and feedback. If an agent summarizes pipeline or answers executive questions, it must be grounded in approved data and tested with realistic user personas. The admin should verify that the agent does not reveal records, fields, files, or report details beyond the user's authority. AI output should be treated as a generated response that needs governance, not as a new security boundary.

Use Agentforce where it helps users act on trusted information, such as summarizing a visible account plan, explaining why a dashboard metric changed, or guiding a service manager to cases that already appear in their queue. Do not use AI to bypass report access, infer hidden data, or make regulated decisions without human review and approved controls. Monitor usage, feedback, audit signals, and data grounding quality after deployment. If the data is stale, duplicated, or poorly secured, AI will amplify the issue.

Executive dashboards should have owners and review cycles. A quarterly operating dashboard should be reviewed after changes to fiscal year settings, territory models, sales stages, case milestones, products, currencies, or automation. If a KPI depends on imported data from an external system, include the load status or freshness indicator. Leaders need to know whether they are looking at current data, a snapshot, or a stale refresh.

Study trap: do not grant View All Data or Export Reports to solve every analytics complaint. Broad permissions can create serious exposure. If the problem is a missing folder share, grant folder access. If the problem is a private sharing model, evaluate sharing rules or role hierarchy. If the problem is a dashboard that should show each viewer only their own rows, use a dynamic dashboard when available. The right fix is the smallest permission and design change that meets the reporting requirement.