If you have ever built a chart widget by pointing it straight at a sheet, you have probably run into one of these problems: a chart that is missing rows, a chart that pulls in rows it should not, or a stakeholder asking why they can see data they should not be able to see. In most cases, the fix is not a different chart type. It is a different source. This article looks at when you should build your dashboard chart widgets from reports rather than sheets.
Build a chart from a sheet when it only ever needs data from that one sheet, and everyone who can view the dashboard is already allowed to see that sheet in full.
Build a chart from a report when you need it to pull data from more than one sheet, when you need to filter or reshape what appears before it reaches the chart, when you need to show that data to people who should not have direct access to the source sheets, or when the source sheet keeps getting new rows over time.
This is the criterion that catches people out most often, because it does not show up as a problem until weeks after the chart was built. A chart widget built from a sheet does not read the whole sheet. It reads a fixed range you selected when you built it, whichever rows and columns you highlighted at the time. When someone adds a new row to that sheet later, whether through a form submission, an integration, or someone typing a new line, the chart does not pick it up. It keeps showing the original selection until someone opens the widget and manually extends the range.
That is manageable if the sheet never grows. It becomes a real maintenance burden on any sheet where rows are added regularly: intake logs, ticket sheets, weekly status entries, anything fed by a form. A report solves this properly. A report's row selection is defined by criteria, not by a fixed range, so any new row that matches the report's filter appears in the chart the next time it refreshes, with no one needing to go back and touch the widget. If your source sheet is a moving target, a sheet-based chart is the wrong choice regardless of how simple everything else about it looks.
A chart built from a sheet can only chart that one sheet. If you need a chart that rolls up status across ten project sheets, or plots every open ticket across a whole portfolio, a sheet cannot do that on its own. A report can. Reports pull rows or sheet summary data from multiple sheets, up to a very large number of source sheets, and present them as one dataset for the chart to plot. Once your chart needs to represent anything above single-project level, a report stops being optional and becomes the only realistic option.
A report is not the only way to get there. Cross-sheet formulas or cell links can pull data from several sheets into one sheet, and a chart can then be built straight off that consolidated sheet. This is worth knowing about, but for anything beyond a handful of source sheets it tends to be more setup and more upkeep than one report doing the same job.
One nuance worth knowing if your source sheets keep multiplying, project sheets spun up by Control Center being the obvious case: a report only auto-includes new sheets if its source is set at the workspace level. If the source is set at the folder level instead, a new sheet added to that folder later does not automatically join the report, it has to be removed and re-added for the new sheet to be picked up. It is the same "new things do not appear on their own" trap as the fixed chart range, just one level up, so it is worth setting reports up against workspaces rather than folders wherever the sheet count is expected to grow. And on genuinely large builds, it is worth knowing that reports can slow down or struggle to open well before any documented ceiling, so a portfolio report spanning several thousand sheets is worth testing early rather than assuming it will scale.
You can filter a chart widget after the fact, but you are still working with whatever the sheet contains. A report lets you narrow the dataset upstream: only high-priority rows, only rows modified in the last thirty days, only rows belonging to a certain owner. That filtered dataset is what feeds the chart. This matters for two reasons. First, it keeps your dashboard configuration honest and easy to audit later, because the logic lives in one place (the report) rather than scattered across several chart widgets. Second, for very large sheets, filtering at the report level keeps things running efficiently, since you are not asking every chart to churn through the full dataset separately.
This is the point that catches people out. Dashboard viewers do not automatically need access to a sheet just because a chart on the dashboard pulls from it, provided that chart is built from a report rather than the sheet directly. In other words, reports let you show a summarised or selected chart to an audience such as executives or clients, without handing them Editor or Viewer rights on the underlying working sheets. If you have ever needed to share a dashboard externally, or with a stakeholder who should only see the top-line chart rather than every row of raw project data, a report is what makes that possible. A sheet-based chart cannot offer that separation. Anyone viewing it needs their own sharing permission on the sheet, full stop.
It is very common to see a dedicated "metrics" or "helper" sheet built purely to feed charts, full of SUMIFS or COUNTIFS formulas that pre-calculate totals by status, by owner, by month. Sometimes this is genuinely the right call: charts need real aggregation logic that goes beyond what a report's grouping can do, so a formula-driven sheet is the cleanest way to get there. But just as often, the real reason is that the source data was never structured with the chart in mind, and the report or grouping route was not obvious as an alternative. Learn more here about how to structure your data properly in Smartsheet, so you do not hit this limitation and stay flexible with your choices.
Two things are worth knowing before reaching for a metrics sheet by default. First, the chart widget reads whatever sits in the top row and the left column of your selection as its labels, the top row becomes the legend or axis categories and the left column becomes the row labels, so a chart built straight from a report or sheet often looks wrong simply because the labels are not sitting where the widget expects them, not because the underlying numbers are wrong. Fixing the layout of the source, rather than pre-processing the numbers elsewhere, solves most of what people build a metrics sheet to solve.
Second, the chart widget editor has a "switch rows and columns" option that swaps which axis reads as labels and which reads as data series, without touching the source sheet or report at all. A lot of "the chart looks flipped, so I will restructure the data" moments are solved with this one toggle. Reports also support row grouping and summary output that can feed a chart directly in many cases, so the gap between "what a report can hand a chart" and "what a metrics sheet can hand a chart" is narrower than it used to be. It is worth trying the grouping and the toggle first, and keeping the helper sheet for the cases where the aggregation logic genuinely needs it.
None of this means reports are always the answer. If a chart is meant to reflect exactly one sheet, with no filtering or combining needed, and everyone viewing the dashboard is already shared to that sheet at an appropriate level, pointing the chart straight at the sheet is simpler and one less object to maintain. A single project's status breakdown, charted straight from that project's own sheet, is a good example: there is no need to wrap it in a report first if nothing needs combining or hiding.
The exception worth knowing: sheet summary reports (reports built from sheet summary data rather than rows) are the only way to combine summary-level figures across multiple sheets into a single chart. If you need one chart that rolls up several project sheets into a portfolio view, this is the mechanism, and it is a report, not a sheet, that gets you there.
Ask yourself these questions before choosing a source for each chart:
One thing worth flagging for anyone scaling this up: reports cannot be built from other reports. If you find yourself wanting to create a report from a report, that is usually a sign the underlying sheet structure needs attention (staging sheets, a reference table, or a cleaner roll-up structure), rather than a sign you need another layer of reporting. It is worth solving that at the sheet level rather than trying to work around it at the dashboard.
If you're going to build reports based on month, you're going to want to read this: Smartsheet Reference Tables: Build Once and Use Them Forever. With this you should be equipped to add months to all of your sheets so they can be added in your reports in the correct order.
Sheets are fine for simple, single-source, fully-shared charts on data that does not grow. The moment a chart needs to combine sheets, filter data before it reaches the dashboard, protect the underlying data from people who only need the summary view, or stay current as new rows come in, a report is the tool built for that job. Getting this right at the start saves a lot of chart rebuilding later, and it is one of the most common gaps we see when reviewing dashboards that have grown organically over time.
If you are working through this on a dashboard chart of your own and want a second pair of eyes on the structure, get in touch through the contact form below and we can take a look together.