Topic Dashboards and data

How to build interactive dashboards in Power BI

The short answer

To build interactive dashboards in Power BI, shape your data in Power Query, model it as a star schema, write measures in DAX, and lay out a few visuals around one question. Then add slicers, cross-filtering, drill-through, bookmarks and report-page tooltips, design a mobile layout, test with real users and publish to the Power BI service.

Written by

Siddharth Kajaria, Founder and CEO

Published

Updated

Reading time

11 min read

A woman placing a red block on a model city whose buildings form a bar chart
In this post11 min read
  1. Reports and dashboards: a note on terms
  2. Before you open Power BI: one question and one audience
  3. Step 1: connect and shape the data in Power Query
  4. Step 2: build a star schema
  5. Step 3: write measures in DAX
  6. Step 4: lay out the page around the question
  7. Step 5: add interactivity
  8. Step 6: design the mobile layout
  9. Step 7: test, publish and share
  10. When interactivity helps, and when a static view is better
  11. Adding the storytelling layer
  12. Dashboards built for the public: what we’d carry over
  13. Common mistakes

Key takeaways

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.

  1. Shape the data

  2. Build a star schema

  3. Write measures

  4. Lay out the page

  5. Add interactivity

  6. Design for mobile

  7. Test and publish

Planning a dashboard?

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:

  1. Top row: three or four headline numbers (cards) that answer the main question at a glance.
  2. Middle: the main trend over time, usually a line or column chart.
  3. Bottom or side: the breakdown, such as a bar chart by region or a table of the items behind the numbers.
  4. 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.

6 interactive features

Filter and focus

  1. Slicers

    Use it when
    Viewers own different regions, products or teams and need to see their own slice.
    Where it goes wrong
    Too many slicers: each one is a decision the viewer has to make before they see an answer.
  2. Cross-filtering and edit interactions

    Use it when
    One visual is the natural starting point and the others explain it.
    Where it goes wrong
    A headline card that changes when someone clicks a bar. Turn it off where the total should always show.
  3. Field parameters

    Use it when
    Several near-identical charts differ only in the measure or the breakdown.
    Where it goes wrong
    Viewers forget what the chart is set to. Make the chosen measure part of the visual’s title.

Go deeper

  1. Drill-down and drill-through

    Use it when
    People need to find the cause behind a number on the summary page.
    Where it goes wrong
    Nobody knows it exists. Say on the page that a right-click opens the detail.
  2. Bookmarks and buttons

    Use it when
    The same data reads better two ways, or viewers often get lost in their own filters.
    Where it goes wrong
    A bookmark that also saves a filter you didn’t mean to keep, so the view shows the wrong data.
  3. Report-page tooltips

    Use it when
    One more number would help, but the page has no room for another visual.
    Where it goes wrong
    Viewers who never hover never see it, so put nothing essential in a tooltip.

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:

An interactive report and a static view compared
Compared onInteractive reportSlicers, drill-through, bookmarksStatic viewA few fixed pages
The viewersThey own different regions, products or teamsEveryone needs the same headline
What they needTo find the cause behind a numberOne clear finding
How often they use itOften, and they know the dataOnce, in a meeting or a report
Ways to slice the dataMany valid onesExtra choices would distract from the decision
Best whenRegional managers check it weekly and each needs their own view, through slicers and drill-throughA board meeting needs a few clear, fixed pages with the finding in each title

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.

01

While you build

  • Starting with visuals instead of the question. The page ends up showing everything and answering nothing.
  • Skipping the data model. Slicers that don’t filter, totals that don’t match and slow pages usually trace back to the model.
  • No mobile layout. A desktop page shrunk to a phone is unreadable.
02

When people use it

  • Too many slicers. Each one is a decision the viewer has to make.
  • Leaving default interactions on everywhere. Some cross-filtering confuses more than it helps.
  • Publishing without testing on real users. What’s obvious to the builder rarely is to the viewer.

02 FAQ

Questions, answered

How often should a Power BI report refresh?
Match the refresh to how often the source data changes and how quickly people act on it. Many business reports are fine with a daily refresh after the source systems settle overnight. Refresh more often only when decisions depend on it, and check the refresh limits for your licence first.
How many visuals should a Power BI report page have?
As few as answer the page's question, often somewhere between three and eight. Every visual adds load time and competes for attention. If a page needs more, split it into an overview page and detail pages joined by drill-through or buttons.
Why is my Power BI report slow?
The usual causes are too many visuals on a page, a model with wide tables or many-to-many relationships, complex measures and DirectQuery sources that answer slowly. Use Performance Analyzer in Power BI Desktop to see which visual takes longest, then simplify the model, the measures or the page.
Can I use Power BI for a public dashboard?
Power BI's Publish to web option makes a report public to anyone with the link, with no sign-in, so use it only for data that is meant to be fully public, and check whether your organisation allows it. For private data, share inside your organisation or embed with sign-in. Some public dashboards are better built as a custom web page.