Power BI visual interactions: a checklist before you publish

Interactions are the part of a Power BI report nobody checks until a reader clicks something and the numbers stop making sense. Here is what to check before you publish.

Before you publish a Power BI report, check six things about how its visuals interact: the default interaction, each visual's overrides, drill behaviour, slicers, performance, and how it behaves for a real reader. Interactions are the part of a report most often left untested, and the part readers notice first.

A report can have the right data, the right measures and a clean design, and still confuse people the moment they click on it. A headline figure that moves when it should not. A chart that fades into noise. A slicer that affects one visual and not the one next to it. None of these show up until someone uses the report.

1. Set the default deliberately

Decide whether the report should cross-highlight or cross-filter by default, and set it in Report settings. For most operational and management reports, cross-filter is the cleaner default. Whichever you choose, make it a decision rather than an accident, and set it in your report template so every new report starts the same way.

2. Review each visual's overrides

Open Edit interactions on the Format tab and click through each visual on each page. For every pair, ask whether the response makes sense for the question the visual answers.

• Headline totals, targets and benchmarks usually want none.
• Visuals that explore a selection usually want filter.
• Visuals that show share of the whole may want highlight.

We set out how to choose in cross-highlight or cross-filter.

3. Decide how drill-down behaves

By default, drilling down in a visual only changes that visual. If readers expect the rest of the page to follow, change the setting that applies drill-down filters to the entire page. Check the choice with someone who will use the report, because either behaviour can surprise a reader who expects the other.

4. Check slicers and their reach

Slicers filter by default, but they do not have to affect everything. Check that each slicer reaches the visuals it should and leaves alone the ones it should not, such as a company total that should ignore a region slicer. If slicers need to carry across pages, check they are synced consistently, so a reader does not change a date on one page and find it ignored on the next.

5. Think about performance

Every selection makes Power BI refresh the visuals it affects. On a busy page with a heavy model, that can mean a noticeable wait after every click.

• Set none on visuals that add nothing when filtered. It also saves a query.
• Consider the query reduction options in Power BI Desktop, which can add an Apply button to slicers or the filter pane, so readers make several choices before anything recalculates.
• Test on the capacity and data volume the report will run on, not on a sample.

6. Test as a reader, not as the builder

The person who built the report knows how it is meant to work. A reader does not. Before publishing, ask someone who will actually use it to click around for ten minutes and say what surprised them. Check it with row-level security applied too, since the numbers a restricted user sees can make a highlighted slice look very different.

It is a short test. It catches more interaction problems than any amount of reviewing your own work.

Make it part of the release

This checklist fits naturally into a release process. If your reports already move through development and test workspaces, the test stage is where interactions should be checked, before anything reaches the business. We covered that in why DEV, TEST and PROD matter and what to check after a deployment.

If you would like help making report design and behaviour consistent across your estate, talk to our Power BI team or start with a free analytics audit.

A report is not finished when it looks right. It is finished when it behaves right.