DASHBOARDS & GRIDS
Dashboard vs report
A report is a point in time, sent to people. A dashboard is a live view, opened by people. Most teams need both and build the wrong one first.
- Opened by people, when they need it
- Live: current to the last refresh
- Filters, click to focus, period comparison
- Saved views for the questions that recur
- Not a record of what was true on a date
- Sent to people, on a schedule
- A point in time, kept as it was
- Fixed layout; reads the same for everyone
- Reaches people who never open a dashboard
- Cannot answer the next question
Two different objects
The words get used interchangeably, which is how teams end up with a "dashboard" that is a PDF and a "report" that nobody can find a copy of from last quarter. They are different objects with different jobs. A dashboard is a screen somebody opens: it is current, it has filters, it answers the question you have and then the next one. A report is a document somebody sends: it is a point in time, it reads the same for everyone, and it stays as it was when it was made. Both have a place. The trouble starts when one is asked to do the other's job.
What a dashboard is for
Monitoring and working. An operations manager opens the dashboard at nine, sees the KPI tiles and the regions chart, filters to her own stores, clicks the region that looks off and watches every widget refocus. The Urgent orders saved grid shows 14, and she works through them. Period comparison shows this week against last without anyone building a second chart. The dashboard is a place to stand while making decisions, and its value is that it is live and interactive: it answers the question you came with and the one you think of next.
What a report is for
Distribution and record. The month-end pack goes to the board, who will not log in to anything. The compliance summary has to exist as it was on the last day of the quarter, unchanged, so that a question six months later can be answered from the same document. The weekly summary lands in an inbox at eight on Monday for people whose job is not to watch a dashboard but to know roughly where things stand. A report reaches people a dashboard never will, and it is a record in a way a live view cannot be.
A report also carries authority in a way a dashboard does not. A signed-off month-end pack is the number; a dashboard opened on the third of the month is a number that may already differ, because late orders arrived. Finance, audit and the board run on documents for that reason, and no amount of interactivity replaces a page that says what was true, when, and who approved it.
Side by side
| Criterion | Dashboard | Report |
|---|---|---|
| Who initiates | The reader opens it | The sender schedules it |
| Time | Live: current to the last refresh | Fixed: what was true when it ran |
| Interaction | Filters, click to focus, period comparison | None; it reads the same for everyone |
| Definitions | Shared, built in once | Shared if generated from the dashboard; private if exported by hand |
| Reach | People who log in | People who do notInbox, print, board pack |
| Record | Not kept as of a date | Archived as it was |
| Follow-up | Ask the next question in place | Start again |
| Best for | Monitoring, exploring, daily work | Distribution, sign-off, compliance |
Where each fails when used for the other
The dashboard as a report. Screenshots of a dashboard pasted into a slide are a report with none of the virtues of one: no fixed definition, no record, and a number that may have changed by the time the slide is shown. If a dashboard view has to be sent, it should be exported from the dashboard, with its filters and its "as of" time, so the document and the screen agree.
The report as a dashboard. A report that is re-run every hour and emailed to forty people is a dashboard that has been denied its filters. Nobody can click it, nobody can narrow it to their own region, and the questions it provokes have nowhere to go. The forty people would be better served by one dashboard and a saved view each.
A useful test for which one a request really is: ask whether the person will look at it once or return to it. Once, on a date, for the record: a report. Returning, to see what changed: a dashboard, and probably a saved view of it. Most "can I have a report of" requests are the second kind wearing the first kind's name.
The ground between: saved views and exports
Most of the gap closes with two features. A saved view turns a filtered dashboard into something as reliable as a report - the same definition, opened by name every day - while staying live. And exporting the data behind a widget, when you need it elsewhere, turns a dashboard moment into a document without a screenshot. Saved views as a workflow covers the first; the second is one click on the widget.
One habit makes the two agree: generate every report from the dashboard's own definitions and filters, and stamp it with the refresh time. A report produced that way is a dashboard view with a date on it. A report produced from a separate query, however careful, is a second definition waiting to disagree with the first.
Which to build first
The dashboard. Every report is a dashboard view frozen and sent: the month-end pack is the finance dashboard filtered to the month, exported on the first of the next. Build the dashboard on an indexed copy with definitions set once, and reports fall out of it, consistent with what people see on screen. Build the reports first and you have a set of documents that each carry their own definition, and the dashboard built later will disagree with all of them. Every team has its own numbers is what that disagreement looks like from the meeting room.