6.5 Dashboards, Components, Subscriptions, and Sharing Impact

Dashboard building blocks

A Salesforce dashboard is a collection of components built from source reports. Components can display charts, tables, metrics, gauges, and other visual summaries depending on the report format and dashboard experience. The dashboard does not fix report logic. If the source report has the wrong report type, missing filters, poor grouping, or a visibility assumption that does not hold, the dashboard will present that problem more attractively but not more accurately.

Admins should design dashboards around decisions. An executive dashboard may show bookings, pipeline coverage, renewal risk, case backlog, and customer health. A service manager dashboard may show open cases by priority, average age, SLA breaches, and agent workload. A data quality dashboard may show records missing required operational fields. Each component should answer one question. A dashboard with twenty unrelated charts often creates less clarity than a dashboard with six well-labeled decision metrics.

Dashboard filters let viewers change the lens without editing source reports. For example, one sales dashboard can filter by region, business unit, or fiscal period. Filters are useful, but they should be constrained to meaningful values. A dashboard filter cannot overcome a report type that excludes the needed records. It also does not override security. The viewer still sees data according to the dashboard's running user model and their access to the dashboard itself.

Folder sharing is the first access gate. Users need access to the dashboard folder to see a dashboard. Report folders control access to source reports. A user may be able to see a dashboard but not open the underlying report if the report folder is not shared with them. That can be a valid design for executive dashboards, but it should be intentional and documented.

Running user, dynamic dashboards, and subscriptions

The running user setting is one of the most tested and most misunderstood dashboard concepts. A dashboard can run as a specified user, meaning dashboard data is evaluated using that user's record visibility. If the running user is a high-access executive, viewers may see aggregate results that include records they could not see in a normal report. A dynamic dashboard runs as the logged-in user, so each viewer sees results based on their own access. Dynamic dashboards are valuable for manager and rep dashboards but have edition and limit considerations that admins should verify in the org.

Decision guide:

1. If every viewer should see the same executive-wide metrics, consider a specified running user with appropriate authority.
2. If each viewer should see only their own accessible records, use a dynamic dashboard when available.
3. If managers need team rollups, confirm role hierarchy, team selling, territories, and dashboard permissions.
4. If the dashboard shows sensitive aggregates, review whether the running user model is acceptable to data owners.
5. Test as at least three personas: executive, manager, and frontline user.

Subscriptions send dashboard or report updates on a schedule or when conditions are met, depending on feature availability. They are useful for weekly pipeline summaries, daily exception lists, and support backlog alerts. But they can become noise if the dashboard refreshes before integrations finish loading data or if recipients do not understand the metric. Admins should align refresh timing with data processes, such as nightly ETL, case escalation jobs, or month-end close.

Refresh behavior matters. A dashboard may not show real-time data until it is refreshed, and scheduled refreshes should be timed to business need. If a manager complains that a dashboard is wrong, ask when the source report was last refreshed, whether the dashboard has been refreshed, whether the source report filters changed, and whether the viewer is comparing the dashboard to a report run under a different user context.

Sharing impact scenario: a regional manager sees 40 opportunities in a source report but a dashboard component shows 250. The dashboard runs as the VP of Sales. The component is not necessarily broken; it is using the VP's visibility. If the requirement is for each manager to see only their region, a dynamic dashboard or separate dashboards with appropriate running users may fit better. If the requirement is executive transparency across regions, the specified running user may be correct.

Dashboard governance checklist:

• Confirm the business owner for each dashboard and source report.
• Store dashboards and reports in folders shared with the right users or groups.
• Choose specified running user or dynamic behavior deliberately.
• Review object, field, and record visibility for the intended audience.
• Set refresh and subscription schedules after data loads complete.
• Add dashboard filters only when they match real decision dimensions.
• Retire unused dashboards so teams do not rely on stale definitions.

Study trap: a dashboard is not a substitute for security design. It can summarize data through the running user model, but the underlying sharing model, object permissions, field-level security, folder sharing, and report permissions still govern what users can access and investigate. Admins earn trust by making that model explicit before executives depend on the numbers.