Creating a Power BI Dashboard from a Report - What Actually Works

Ask most executives what they want from Power BI and they'll say "a dashboard". Then you build them a 12-page report with slicers, drill-throughs and tooltips, and they open it once. What they actually wanted was one screen they can glance at on Monday morning, see that nothing is on fire, and get on with their day.

That's the gap Power BI dashboards were designed to fill. And because "dashboard" gets used to mean almost anything with a chart in it, plenty of Australian organisations we work with have never built one in the Power BI sense of the word. They have reports. Lots of reports. But no single page that pulls the important numbers from all of them into one place.

This post walks through how you create a dashboard from a report in the Power BI service, what we've seen work on client projects, and where the feature is showing its age.

Reports and dashboards are different things

This trips people up constantly, so it's worth being precise.

A report is what you build in Power BI Desktop (or in the service). It can have many pages, it's interactive, you can filter and slice and drill into it, and it's tied to a single semantic model.

A dashboard only exists in the Power BI service. It's a single canvas made up of tiles, and each tile is pinned from somewhere else: a report visual, a whole report page, a Q&A answer, an Excel range, an image. The big difference is that a dashboard can pull tiles from multiple reports built on multiple semantic models. Your sales figures from the CRM model, your cash position from the finance model and your safety incidents from the operations model can all sit side by side.

You can't build a dashboard in Power BI Desktop. If someone on your team is hunting for the "new dashboard" button in Desktop, that's why they can't find it.

How to pin visuals from a report to a dashboard

The mechanics are simple. Microsoft's documentation on creating a dashboard from a report covers the clicks in detail, but here's the short version:

1. Publish your report from Desktop to a workspace in the Power BI service.
2. Open the report in the service, in reading view is fine.
3. Hover over the visual you want and select the Pin visual icon (the pushpin).
4. Choose whether to pin to an existing dashboard or create a new one, and give it a name.
5. Pick whether the tile should keep the report's theme or adopt the dashboard's theme.
6. Repeat for the other visuals you want, from this report or any other.

You can also pin an entire report page as a "live" tile. Live page tiles stay interactive, so slicers on that page still work from inside the dashboard. That sounds great, and occasionally it is, but in practice we use it sparingly. A full report page squashed into a dashboard tile is usually too small to read and defeats the purpose of having a summary view.

A few details that matter more than they first appear:

• Filters are baked in at pin time. If you've filtered the report to "NSW only" when you pin a visual, that tile will show NSW only, forever. We've seen a national operations dashboard that quietly showed one state's numbers for three months because someone had a slicer set when they pinned the tile. Check your filters before you click the pin.
• Clicking a tile takes you back to the source. By default, selecting a tile opens the report page it came from. This is the best feature of dashboards and the reason the "summary up top, detail underneath" pattern works so well.
• You need the right permissions. You need to be able to edit content in the workspace to pin. Viewers can look at the dashboard but can't add tiles to it.
• Tile data refreshes with the semantic model. Dashboard tiles have their own cache that updates after the underlying model refreshes. If a tile looks stale after a refresh, give it a few minutes or refresh the dashboard tiles manually before you assume something has broken.

Designing a dashboard people actually look at

The technical side takes ten minutes. The design side is where most dashboards fail.

Here's what we've found works across finance, logistics and professional services clients.

Start with the questions, not the visuals. Before anyone pins anything, write down the five or six questions the audience asks every week. "Are we on track for the month?" "Which branches are behind?" "Is overdue debt going up?" Each tile should answer one of those questions. If a tile doesn't map to a question, it shouldn't be there.

Keep it to one screen. A dashboard that needs scrolling is a report pretending to be something else. We aim for 8 to 12 tiles maximum, and the top-left corner gets the single most important number because that's where eyes land first.

Use card and KPI visuals generously. A big number with a target comparison does more on a dashboard than a detailed line chart. Save the complex visuals for the report pages people click through to.

Set up data alerts. This is underused. Card, KPI and gauge tiles on a dashboard can have data alerts set on them, so someone gets an email or notification when a value crosses a threshold. One logistics client set alerts on late-delivery percentage and stopped needing a daily check-in meeting about it. That's a better outcome than any visual design choice.

Build the mobile layout. Dashboards have a separate phone layout you can arrange in the service. Most executives we work with check numbers on their phone between meetings, and the default auto-generated mobile layout is rarely good. Spend fifteen minutes arranging it properly.

Where dashboards are still rough

I'll be honest: dashboards haven't been where Microsoft has put its energy for a while. Most of the investment has gone into reports, Fabric, and Copilot. That shows in a few places.

Formatting control is limited. Tile sizes snap to a grid, you get limited control over fonts and spacing, and you can't do the pixel-level layout you can in a report. If your stakeholders have strong opinions about design, they'll find dashboards frustrating.

Pinned tiles aren't fully interactive. Apart from live page tiles, a pinned visual is basically a snapshot of that visual with live data. You can't filter it from the dashboard. People expect slicers, and they're not there.

Governance gets messy. Because anyone with edit rights can pin to any dashboard in the workspace, dashboards drift. Tiles pile up, nobody remembers which report they came from, and the source report gets deleted or renamed and the tile breaks. We now recommend a named owner for every dashboard, with a quarterly tidy-up.

The alternative is often a well-designed report page. A lot of the time, a single summary page at the front of a report, with buttons into detail pages, does the job better than a dashboard. It looks better and supports slicers. The only real reason to go to a dashboard is when you need tiles from multiple semantic models on one screen, or you want data alerts. If everything comes from one model, a summary report page is usually the smarter choice.

That last point is where I'd push back on a lot of advice out there. Dashboards aren't automatically the "executive" layer. They're a specific tool for a specific job: aggregating across models and alerting on thresholds. Use them for that.

A pattern that works well

On a recent project for a mid-sized professional services firm, the leadership team had four separate reports: utilisation, revenue, debtors and pipeline. Each on its own semantic model, each owned by a different person. Nobody had a single view.

We built one dashboard with:

• Three cards across the top showing month-to-date revenue against target, utilisation percentage, and debtors over 60 days
• A line chart of weekly revenue trend from the finance report
• A bar chart of utilisation by practice area from the resourcing report
• A pipeline value by stage visual from the CRM report
• Data alerts on debtors over 60 days and utilisation dropping below 70%

Every tile clicks through to the full report it came from. The managing partner told us it was the first time they'd had the whole business on one screen. Total build time for the dashboard itself was about half a day. The reports underneath took weeks, which is normal. The dashboard is the easy part once the data model is right.

Sharing and licensing

To share a dashboard, you'll generally need a Power BI Pro or Premium Per User licence, or the content needs to sit in a workspace on Premium or Fabric capacity so viewers with free licences can consume it. Sharing a dashboard also gives recipients access to the underlying reports and semantic models, so check row-level security is set up properly before you hit share. We've written separately about Power BI licensing if you need more on that.

For most organisations, the cleaner option is to package the dashboard and its reports into a workspace app and distribute it that way. You can set the dashboard as the landing page so people open the app and see the summary first.

Should you bother?

If you've got a single model and a single audience, probably not. Put the effort into a solid summary page in your report instead.

If you've got leaders who need to see numbers from several different systems in one place, or you want threshold alerts without building a Power Automate flow, then yes. Dashboards are still the quickest way to do that in Power BI, and they take hours rather than days once your reports exist.

The thing that makes or breaks it isn't the pinning. It's whether the semantic models underneath are trustworthy and whether someone owns the dashboard after go-live. That's where most of our Power BI consulting work ends up, frankly: fixing the models so the numbers on the dashboard are numbers people believe. If you're trying to pull reporting together across several systems and want an outside view, our business intelligence team is happy to have a chat.