Power BI Dashboards Explained - What They Are and When to Use Them
Ask ten people in an Australian business what a "Power BI dashboard" is and you'll get ten answers. Most of them will describe a report. That's not a pedantic point. Power BI has a specific thing called a dashboard, it behaves very differently from a report, and mixing the two up is one of the most common sources of confusion we hit when we start working with a new client.
I've lost count of the number of times a CFO has asked for "a dashboard" and what they actually wanted was a single screen they could glance at on their phone at 7am, with an alert if cash dropped below a threshold. That's a real Power BI dashboard. Meanwhile the finance team built them a 14-page report with slicers on every page. Good work, wrong tool.
So let's sort out what dashboards actually are, when they're worth the effort, and where they fall short.
What a Power BI dashboard actually is
In Power BI terms, a dashboard is a single page canvas that lives in the Power BI service (the web portal, not Power BI Desktop). You can't build one in Desktop at all. It's made up of tiles, and each tile is usually something you've pinned from a report: a visual, a whole report page, a Q&A answer, an image, a text box, a video or a web content tile.
The key thing is that a dashboard can pull tiles from many different reports and many different semantic models. That's the whole point of it. A report is tied to one semantic model and gives you an interactive, multi-page view of that data. A dashboard sits above your reports and gives you one page that summarises what matters across all of them.
Microsoft's own introduction to dashboards frames it as a way to tell a story on one screen, and that's about right. Think of it as a front page rather than the whole newspaper.
Dashboards versus reports - the differences that matter in practice
Here's how the two compare in the ways that actually affect what you build:
| Dashboard | Report | |
|---|---|---|
| Pages | One | Many |
| Data sources | Tiles from many reports and semantic models | One semantic model |
| Where you build it | Power BI service only | Desktop or service |
| Filtering and slicing | No slicers on the canvas | Full slicers, filters, drill-through |
| Data alerts | Yes, on card, KPI and gauge tiles | No |
| Featured on home | Can be set as a featured dashboard | Not in the same way |
The bit that trips people up is interactivity. Clicking a tile on a dashboard doesn't cross-filter the other tiles. It takes you to the underlying report (or wherever you've linked it). If your users expect to click on "NSW" and have everything on the screen update, a dashboard will disappoint them. That's report behaviour.
The flip side is alerts. You can set a data alert on a card, KPI or gauge tile so that someone gets an email or notification when a number crosses a threshold. For operational folks this is genuinely useful. A warehouse manager in Brisbane doesn't want to open Power BI every hour to check whether pick backlog is over 400 orders. They want to be told. You can also wire those alerts into Power Automate if you want something more than an email, like posting to a Teams channel or raising a ticket.
When we actually recommend building one
I'll be honest: dashboards are a less important part of Power BI than they were five or six years ago. Reports have got much better, the mobile app handles reports well, and Microsoft's investment has clearly gone elsewhere (Fabric, Copilot, the newer report features). A lot of organisations we work with have perfectly good Power BI setups with zero dashboards in them, and that's fine.
But there are three situations where we still reach for them.
Executives who want one screen across several domains. If the CEO wants sales, cash, safety incidents and headcount on one page, and those live in four different semantic models owned by four different teams, a dashboard is the cleanest way to do it without building a monster semantic model that combines everything. Each team keeps ownership of their own report, and the dashboard just pins the headline numbers.
Threshold monitoring. Anything where the question is "tell me when this goes wrong" rather than "let me explore this". Overdue invoices over a certain amount, stock levels, SLA breaches. Alerts on dashboard tiles are a cheap way to get this without building a separate monitoring tool.
Wall screens and TV displays. A dashboard in full screen mode works well on a TV in an office or operations floor. It's one page, it doesn't need anyone to click anything, and it refreshes on its own. We set one up for a logistics client whose dispatch team had been printing a spreadsheet every morning and sticking it on the wall. It wasn't a big project, but people noticed it on day one.
If none of those apply, build a well-designed report and skip the dashboard. You'll have less to maintain.
Things that catch people out
A few practical things we see go wrong regularly.
Tile refresh isn't the same as data refresh. Dashboard tiles cache their data. When the underlying semantic model refreshes, the tiles update shortly after, but there can be a lag. For DirectQuery models, tiles refresh on a schedule you can configure (the default is hourly). We've had clients ring us convinced their data pipeline was broken when it was just the dashboard tile cache being behind the report. If something looks stale, open the underlying report and compare.
Pinning a visual freezes some of its context. When you pin a visual, it keeps the filters that were applied at the time you pinned it. If you later change the report's default filters, the pinned tile doesn't follow. This is how you end up with a dashboard tile showing "FY25 Revenue" two years later because someone pinned it with a year filter set. Pinning a whole live report page avoids this, because live page tiles stay in sync with the report, but they're bigger and less flexible on layout.
Row-level security still applies, but test it. If the underlying semantic model uses row-level security, each viewer sees tiles filtered to their own data. That works well, but we always test it with real user accounts before rollout. A dashboard that pulls from five semantic models has five sets of RLS rules, and it only takes one to be misconfigured for a regional manager to see national numbers they shouldn't.
Licensing. To share a dashboard, you need a Pro or Premium Per User licence, and so do your viewers, unless the workspace sits on a Premium or Fabric capacity (F64 or above), in which case free-licence users can view. This catches out smaller organisations that build something great and then discover half the leadership team can't open it.
Mobile layout is a separate job. Dashboards have a phone view that you lay out separately from the web view. If you don't bother, Power BI stacks the tiles in a default order that's often unhelpful. It takes ten minutes to fix and makes a big difference for executives who mostly look at this stuff on their phones on the train.
Designing a dashboard people will actually look at
The best dashboards we've built have a few things in common.
They're small. Six to ten tiles, not thirty. If you need thirty tiles, you need a report.
The most important number is in the top left. People read screens the same way they read a page, and the first tile gets the most attention. Put the thing the audience cares about most there.
Every tile answers a question someone actually asked. Before we build a dashboard, we ask the people who'll use it what decisions they make each week and which numbers they look at to make them. That list becomes the tile list. Anything that's "nice to know" goes in the underlying report.
Tiles link somewhere useful. By default a tile takes you to the report it came from, but you can set a custom link. For a sales tile, linking straight to the page that breaks sales down by region saves people two clicks and a bit of frustration.
Titles and subtitles are written for humans. "Sum of NetAmt" is not a title. "Revenue this month vs target" is. You can override tile titles and subtitles on the dashboard without touching the report, so there's no excuse.
Where dashboards fit with Fabric and Copilot
If you're on Microsoft Fabric, you'll notice there's also a "Real-Time Dashboard" item, which is a different thing built on Real-Time Intelligence and KQL. It's aimed at streaming and operational data, refreshes in seconds, and lives in a different part of the platform. Don't confuse the two. For classic business reporting on data that refreshes a few times a day, the standard Power BI dashboard is still the right fit.
Copilot in Power BI is also changing how some executives consume data. Instead of glancing at a dashboard, they ask a question. We're seeing a mix in practice: people still want a fixed front page they can check without thinking, and they use Copilot for the follow-up questions. A good dashboard plus a well-modelled semantic model behind it is still the foundation either way. Copilot can't fix a bad model, and it's pretty good at exposing one.
If you're thinking about how AI fits into your reporting more broadly, our AI for business intelligence work covers where that's genuinely useful and where it's still hype.
My honest take
Dashboards in Power BI are a useful, slightly neglected feature. They do one thing well: summarise many reports on one page and alert you when numbers move. They're not where you'll spend most of your Power BI effort, and you shouldn't try to make them do the job of a report.
If you're starting out, build your semantic models and reports properly first. Then, once you know which handful of numbers people check every day, pin those to a dashboard and set some alerts. That order matters. We've seen organisations start with the dashboard, work backwards, and end up with a pretty front page sitting on top of a mess.
If you'd like help working out what your organisation actually needs, whether that's a dashboard, a set of reports or a full reporting overhaul, our Power BI consultants do this every week for Australian businesses. And if your data platform is moving to Fabric at the same time, have a look at our Microsoft Fabric consulting too.