A Report, by default and always, respects each individual viewer's own record-level access as governed by the Sharing Model from Module 5 — Organization-Wide Defaults, Role Hierarchy, Sharing Rules, and Manual Sharing all apply exactly as they would if that user browsed the underlying records directly, meaning two different users running the identical report can see different results based on their own genuine access. A Dashboard, by contrast, has an explicit "Run As" configuration choice that determines whose access is actually used: "Run as Dashboard Viewer" replicates the Report-like behavior of respecting each individual viewer's own access, but "Run as Specified User" instead shows EVERY viewer the exact same data, filtered by one chosen user's access, regardless of what the actual viewer's own permissions would normally allow them to see. This means Dashboards, unlike Reports, have a genuine, deliberate choice to make about whether viewer-specific access is respected at all, which is precisely why Run As is considered such a consequential Dashboard configuration decision.

This creates a genuine data exposure risk because every Sales Rep viewing this Dashboard will see the COMPLETE, company-wide data reflected in the System Administrator's full access, regardless of what their own individual record-level permissions under the normal Sharing Model would otherwise allow them to see — effectively bypassing Organization-Wide Defaults, Role Hierarchy, and Sharing Rules entirely for anyone viewing this specific Dashboard. If Sales Reps are normally restricted to seeing only their own Opportunities through the standard Sharing Model, but this Dashboard shows aggregated or detailed data reflecting EVERY Rep's Opportunities company-wide because it runs as the broad-access Administrator, those Reps are now able to see data through the Dashboard that they were never intended to have access to through any other part of the system, representing a genuine, easy-to-overlook security gap that undermines the careful record-level access design built throughout Modules 3 through 5.

Dynamic Dashboards solve this specific requirement, using the "Let Authorized Users Choose Who to View As" Run As option, which allows a single, shared Dashboard definition to automatically personalize its displayed data for each different authorized viewer based on THEIR OWN record-level access, rather than requiring the Admin to maintain separate Dashboard copies configured with each individual Manager set as a hardcoded "Specified User." When a Manager views a Dynamic Dashboard set to view "as themselves," the data shown reflects exactly what their own position in the Role Hierarchy and broader Sharing Model access already grants them — typically their own team's aggregated data, since that is what a Manager's Role Hierarchy position naturally provides visibility into. This means one single Dashboard definition genuinely serves every Manager differently and correctly, eliminating the maintenance burden of building and keeping synchronized a separate Dashboard for every individual Manager as the organization grows.

A Chart Component, whether Bar, Line, Pie, or Donut, fundamentally requires GROUPED data to render meaningfully — it needs distinct categories along one dimension (such as Stage names) paired with a summarized value for each category (such as Sum of Amount) to actually plot as a visual chart. A Tabular-format report, as covered in Module 19, is specifically a flat list of individual rows with no grouping and no subtotals whatsoever, meaning there is no natural category-to-value pairing available for a chart to visualize — attempting to chart raw, ungrouped Tabular data would either be unavailable as an option entirely, or would produce a nonsensical result with no meaningful categorical structure to plot against. A Summary or Matrix format report, by contrast, inherently provides the grouped structure with associated summarized values that a Chart Component needs to render a genuinely meaningful visualization, which is why these formats are the appropriate underlying report choice when the end goal is a Chart Component rather than a Table or Metric.

The most likely issue is that the Dashboard does not have Scheduled Refresh configured, meaning its displayed data only updates whenever someone manually clicks the Refresh button, and if nobody has done so in three days, the Dashboard continues showing exactly the data as of that last manual refresh, regardless of how much the underlying records have actually changed since then. The fix is to open the Dashboard, use the Refresh dropdown to select Schedule Refresh, and configure an appropriate automatic frequency, such as Daily at a specific early-morning time before the Executive typically checks it, ensuring the data refreshes automatically every day without depending on any individual remembering to manually trigger it. It is also worth enabling failure notifications on the scheduled refresh, so that if a future refresh ever fails silently for some reason, an Admin is proactively alerted rather than the Dashboard quietly drifting out of date again without anyone noticing until an Executive complains a second time.

The design reasoning centers on visual hierarchy directly supporting how a busy viewer, such as an Executive checking the Dashboard for perhaps thirty seconds each morning, actually consumes information: leading with a single, large, prominent Metric representing the most important headline number immediately communicates the one thing that matters most, without requiring the viewer to study or compare multiple equally-weighted Components to figure out what they should focus on first. Following this with progressively more detailed supporting Components, sized and grouped to visually signal their relative importance beneath the headline, lets a viewer who wants more context naturally drill deeper at their own pace, while a viewer who only has time for the headline number still gets genuine value from a five-second glance. Presenting 15 equally-sized Components with no deliberate hierarchy forces every viewer to do the cognitive work of identifying what actually matters themselves, every single time they open the Dashboard, which defeats much of the purpose of a Dashboard as a fast, at-a-glance decision-support tool rather than simply a comprehensive data repository requiring active study.