Key takeaways
- Most “interactive Power BI dashboards” are reports: slicers, drill-through and bookmarks live in reports, not in dashboards of pinned tiles.
- Start with one question and one audience. If nobody can name the decision a page supports, it turns into a wall of charts.
- Interactivity flows along the data model, so a clean star schema and DAX measures come before any slicer.
- Add each interactive feature only where it helps the viewer answer their question, and turn off the ones that confuse.
- Design a separate mobile layout, test with real viewers, and use Publish to web only for data that is meant to be fully public.
Reports and dashboards: a note on terms
In Power BI, a report is the multi-page file you build in Power BI Desktop, and a dashboard is a single canvas of tiles that you pin from reports in the Power BI service. Most of what people call an “interactive Power BI dashboard” is a report, because reports are where slicers, drill-through and bookmarks live. This guide builds one.
If you’re new to the tool, start with Power BI for beginners to get Power BI Desktop installed and your first visual on the canvas, then come back here.
Before you open Power BI: one question and one audience
An interactive dashboard works when it answers one main question for one audience. Write both down before you build anything:
- The question. “Which regions are behind on this quarter’s sales target, and why?” is a question. “Sales data” is not.
- The audience. A regional manager checking weekly needs different detail from an executive glancing monthly.
- The decisions. What will someone do differently after looking? If you can’t name a decision, the page will turn into a wall of charts.
- The data. Which tables you need, where they live, how often they refresh, and who owns them.
Sketch the page on paper: the headline numbers, the main trend, the breakdown, and what a viewer will click to go deeper. It’s faster to fix a sketch than a report. Then build it in the seven steps below, in order: each one depends on the one before it.
Planning a dashboard?
Tell us the question your dashboard must answer and who will read it, and we’ll talk through whether Power BI or a custom web dashboard fits.
Step 1: connect and shape the data in Power Query
Connect to your sources from Power BI Desktop with Get data, then clean and shape them in Power Query before they reach the model. Power BI connects to files, databases, cloud services and many online platforms.
In Power Query:
- Remove what you don’t need. Fewer columns and rows make a faster report.
- Fix data types for dates, numbers and text.
- Split, merge and unpivot so each table has one row per thing it describes, such as one row per order line.
- Name things clearly. Table and column names show up in tooltips and the field list.
- Keep the steps. Power Query records every step, so the same cleaning runs on every refresh.
Step 2: build a star schema
Model your data as a star schema: fact tables of events or transactions in the middle, and dimension tables that describe them around the edge. Interactivity depends on this, because slicers and cross-filtering flow along the relationships.
- Fact tables hold the numbers: sales lines, visits, readings, applications.
- Dimension tables hold the descriptions: date, product, region, customer.
- Relationships usually run one-to-many, from a dimension to a fact table, filtering in one direction.
- A date table with one row per day, marked as the date table in Power BI, makes time comparisons reliable.
Avoid many-to-many relationships and two-way filters unless you need them; they make filters behave in ways viewers don’t expect.
Step 3: write measures in DAX
Write the numbers your page shows as DAX measures, rather than dragging raw columns onto visuals. Measures recalculate for whatever a viewer has selected, which is what makes a page interactive.
An illustrative set, assuming a Sales fact table with an Amount column and a marked Date table (adjust the names to your model):
Total Sales = SUM ( Sales[Amount] )
Sales Last Year =
CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
Sales Growth % =
DIVIDE ( [Total Sales] - [Sales Last Year], [Sales Last Year] )
DIVIDE returns a blank instead of an error when last year’s value is zero. Keep measures in a dedicated table, give them clear names, and set their number format once so every visual shows them the same way.
Step 4: lay out the page around the question
Lay out each page so the eye moves from the headline to the detail. A layout that works for most pages:
- Top row: three or four headline numbers (cards) that answer the main question at a glance.
- Middle: the main trend over time, usually a line or column chart.
- Bottom or side: the breakdown, such as a bar chart by region or a table of the items behind the numbers.
- Slicers in one consistent place on every page, usually along the top or left.
Use a consistent colour for each meaning: one colour for actuals, one for targets, one to highlight what needs attention. Give each visual a title that says what it shows. If a page needs more than about eight visuals, split it.
Step 5: add interactivity
Add interactivity where it helps the viewer answer their question, and leave it out where it doesn’t. These are the main tools, grouped by what they do for the viewer: narrow the page down, or go deeper into one number.
Step 6: design the mobile layout
Design a separate mobile layout for each page people will read on a phone. In Power BI Desktop, the mobile layout view lets you place and resize visuals for a portrait screen without changing the desktop page.
- Lead with the headline numbers. On a phone, people want the answer first.
- Use fewer visuals, stacked vertically, at a readable size.
- Keep slicers simple. A dropdown takes less room than a list.
- Test in the Power BI mobile app on a real phone before you share it.
Step 7: test, publish and share
Test your report with the people it’s for, then publish it to the Power BI service. Before you publish:
- Check performance. Performance Analyzer in Power BI Desktop shows how long each visual takes to load. Simplify the slowest.
- Check the numbers. Compare key totals with a trusted source.
- Watch someone use it. Give a colleague the question and see where they click. Where they get lost, simplify.
- Set up row-level security if different viewers should see different data, such as a manager seeing only their region.
Then publish to a workspace in the Power BI service, set a scheduled refresh, and share it with the people who need it, for example as an app for a wider audience. Be careful with Publish to web: it makes the report public to anyone on the internet, with no sign-in, and Microsoft warns that viewers can reach the detail-level data in the model even where the report doesn’t show it. It also doesn’t support row-level security or mobile layouts, and your Power BI admin has to allow it (Microsoft’s Publish to web page, checked 20 October 2026).
When interactivity helps, and when a static view is better
Interactivity helps when viewers have different questions or need to explore; a single static view is better when everyone needs the same answer. Use this to decide:
A report for a board meeting often works best as a few clear, fixed pages with the finding in each title. A report for regional managers checking weekly needs slicers and drill-through.
Adding the storytelling layer
Interactivity lets people explore; storytelling makes sure they don’t get lost. Add a light storytelling layer on top of your interactive pages:
- Order pages around the question: an overview page with the answer, then pages that explain why, then detail pages for each area.
- Write titles that state the finding, such as “Two regions account for most of the shortfall”, instead of “Sales by region”.
- Annotate what matters. A short text box beside a spike explains it better than a legend.
- Use bookmarks as a guided tour. A sequence of bookmarks can walk a viewer through the story, then hand control back to them.
- End with the decision. Say what the numbers suggest doing next.
For the wider craft, from structure to wording, see our guide to data storytelling best practices. For the marketing version of all this, with the five reports to build first, see Power BI for marketing and sales analytics.
Dashboards built for the public: what we’d carry over
The same principles apply when a dashboard is built for the public rather than for a team. We built the GFC EV dashboard and the Renewables India dashboard with the Central Electricity Authority (CEA). Public dashboards raise questions an internal report doesn’t: viewers arrive with no training, on any device, often from a search result, and need the answer before they need the filters. The EV dashboard includes an EV sales-penetration forecast to 2030 and RTO-level data on a map, and Renewables India generates automated reports.
Whether you build in Power BI or as a custom web dashboard, the approach we’d take is the same: one main question per view, a default view that answers it without any clicks, filters for the people who need to go deeper, and a mobile layout designed rather than shrunk. If you need interactive data visualisation for your team, or public dashboards for research that anyone can use, we can help you choose the right tool for the audience.
Common mistakes
Most of these come from building for the builder rather than the viewer. They split into mistakes made while you build and mistakes that only show once people use the report.
