In Short: You Probably Mean a Report
In everyday business language, "dashboard" means a single screen of key numbers. In Power BI, dashboard is a specific object - a service-only canvas of pinned tiles - and it is usually not what people are asking for. The thing most people call a dashboard is, in Power BI terms, a well-designed report page.
The distinction sounds pedantic and costs real money when missed: teams build the wrong object, lose the interactivity users expected, and blame the tool. Two minutes of definitions prevents that.
Reports: The Real Workhorse
A report is what you build in Power BI Desktop: one or many pages of visuals over a single semantic model, with the full interactive kit - slicers, cross-filtering, drill-through, bookmarks, tooltips. Published to the service, it is the primary way people consume data, and modern Power BI features (from design tooling to Copilot) centre on it.
When a stakeholder asks for "a dashboard showing sales at a glance", the professional translation is: a report whose first page is an at-a-glance summary, designed with the discipline our KPI dashboard guide describes, with detail pages behind it for the drill-down. That delivers the language meaning of dashboard with the machinery of a report.
Dashboards: The Narrow Specialist
The dashboard object exists in the service only: you pin tiles from reports (or several reports) onto one canvas. Its genuine advantages are three.
- Cross-model views: tiles from different semantic models on one screen - the one thing a single report cannot do
- Alerts: data-driven notifications on card and gauge tiles when a number crosses a threshold
- A stable front door: a simple landing page that never changes shape, clicking through to the living reports behind it
The costs are everything else: no slicers, minimal interactivity, a separate artefact to maintain, and a second place where content can rot. Pinned live report pages soften some limits, but the object remains what it is: a monitoring veneer, not an analytical surface.
The Decision Rule, and the 2026 Reality
Build a report for anything analytical, interactive or designed - which is nearly everything. Add a dashboard only for the specific trio above: multi-model monitoring, tile alerts, an executive front door. Package either for the audience with apps, which is the distribution layer people actually navigate.
Worth noting how the ground has shifted: alerts increasingly live in Activator with far more power, executives increasingly meet numbers as Copilot summaries in Teams rather than any canvas, and adoption problems were never really about which object - they are about trust and relevance, the territory of our Power BI adoption guide. Get the report right first; the rest is packaging.
Sources and Further Reading
Frequently asked
A report is the primary authoring object: multi-page, fully interactive, built in Power BI Desktop against one semantic model. A dashboard is a service-only canvas of tiles pinned from one or more reports: single-page, lightly interactive, clicking a tile takes you to its source report.
A report, almost always. In everyday language dashboard means an at-a-glance analytical page, and in Power BI you build that as a well-designed report page. Actual dashboard objects are for combining tiles from multiple reports into one monitoring view.
Combine visuals from multiple semantic models on one canvas, carry data-driven alerts on tiles, and serve as a stable landing page for executives. Those are real, narrow advantages; everything else favours reports.
Nearly everything interactive: slicers, cross-filtering, drill-through, bookmarks, tooltips, multiple pages. Reports are where design, analysis and exploration live - which is why they are the default deliverable.
Less each year. Report pages plus apps for packaging cover most monitoring needs, and newer surfaces (Teams, Copilot summaries, metrics-style views) took over some old dashboard roles. We build dashboard objects rarely and deliberately - usually as executive landing pages with alerts.
