Filters and Highlighting in Power BI Reports - What Authors Get Wrong

The single most common Power BI complaint I hear from end users isn't about data quality or performance. It's "I don't know what this report is showing me". Nine times out of ten the cause is filters. Something is filtered somewhere - on the page, on the visual, by another visual cross-filtering it - and the user can't see why the number doesn't match what they expected.

This is fixable. Most of the time it's not a technical issue at all. It's a design choice the report author made without thinking about how an actual person would experience it.

I've been doing Power BI consulting in Australia for years, mostly with mid-market and enterprise clients, and the filter design question keeps coming up. So here's the practical guide I wish I could hand to every new report author on day one.

The four filter levels nobody explains clearly

Power BI has four places filters can live and most authors mix them up. Here's the hierarchy:

Visual-level filters apply to one specific visual. They're invisible to consumers unless the author exposes them. Use these for things like "this chart only ever shows the top 10" or "this table excludes cancelled orders".

Page-level filters apply to every visual on a single page. Good for things like "this page is always about Q4" or "this page only shows the Sydney region".

Report-level filters apply across all pages. Useful for things like fiscal year or division when the whole report is scoped to that context.

Filter pane filters are what the user sees and interacts with. This is the visible filtering experience. The other three exist in the background unless the author chooses to expose them.

The mistake most authors make is putting a filter at the wrong level. A common one: setting a hard "Year = 2026" page filter so all visuals show current year data, then a year slicer that the user thinks they're controlling. They change it to 2025 and nothing happens because the page filter is overriding them. They lose faith in the report.

Rule of thumb: if you want the user to control it, expose it. If you want it locked, put it at visual or page level and hide it from the filter pane. Don't half-do either.

Slicers vs filter pane - which to use when

Slicers are visuals on the report canvas. The filter pane is a separate panel that pops out from the side. Both filter data. They feel different to users.

I default to slicers for the filters that matter most to the report's story. They're visible, they're obvious, they're where the user's eye lands. If the report is about quarterly sales by region and the user always wants to slice by region, put a region slicer on the canvas. Don't bury it in the filter pane.

The filter pane is better for secondary filters that you want available but don't want to clutter the page with. Things like product subcategory, customer segment, or any filter with a long list of values that would dominate the page if shown as a slicer.

A practical pattern that works: three or four slicers across the top of the page for the primary filters, filter pane for everything else. Consistent placement across all pages so users know where to look. We've redesigned a lot of reports following exactly this pattern as part of our Power BI consulting work and it usually improves user satisfaction without changing any of the underlying data.

One slicer trick that's underused: hierarchy slicers. If your filter has natural levels (year > quarter > month, or country > state > city), a hierarchy slicer collapses cleanly and saves a huge amount of space. Most authors don't realise this exists.

Cross-highlighting - the feature users find baffling

When a user clicks a bar in one chart, the other charts on the page update to highlight or filter to that selection. This is Power BI's flagship interaction feature and it's also where users get the most confused.

The defaults are reasonable but not always right. By default, clicking a value in a visual highlights related values in other visuals (showing the selected portion in colour and the rest in grey). For tables and cards, it filters instead of highlights. Authors can change this behaviour per visual pair through Edit Interactions.

What I always tell clients: be deliberate about which visuals interact with which others. The default of "everything filters everything" creates noise. If you click a region and the entire page jumps around, users can't tell what's happening. Better to designate one or two visuals as the "drivers" that filter the rest, and turn off cross-filtering for the remaining visuals.

The Edit Interactions option lives on the Format ribbon under Visual interactions. Worth spending half an hour on a report you own and consciously deciding for each pair of visuals: should clicking A change B? Often the answer is no.

A specific anti-pattern: putting a KPI card and a chart on the same page where the chart cross-filters the KPI. User clicks the chart to drill in, the KPI number changes, user thinks the KPI was wrong before. Disable the interaction. The KPI should show the unfiltered total. Add a separate KPI below it if you want a "selected" total.

Sync slicers across pages - massively underused

This one's an easy win. If you have the same slicer (say, fiscal year) on multiple pages, you almost certainly want them synchronised. User picks 2026 on page 1, navigates to page 2, the slicer is still on 2026.

Power BI does this through the Sync Slicers pane. You can choose which pages a slicer syncs to and whether it's visible on each page. The hidden+synced combination is particularly useful: a slicer that exists on every page but only shows on the first one. Users set it once and it applies everywhere.

Without sync, users have to set the same filter on every page. They forget, the data looks wrong, they file a complaint. Sync the slicers.

Drill-through pages - filters that follow you

When you set up a drill-through page (right-click a value in a visual, choose to drill through to a detail page), Power BI carries the filter context with you. The detail page is filtered to whatever you right-clicked.

This is genuinely one of the better features for designing layered reports. The summary page has high-level visuals, the detail pages have transaction-level data filtered to what the user clicked from. Users get the summary they want and the detail when they need it, without the report becoming a wall of tables.

A few practical notes:

Always add a back button to drill-through pages. Power BI doesn't add one by default and users get stranded.

Use the drill-through page header to show what filters are applied. A simple title that says "Detail for Region: NSW, Product: Widget" tells the user exactly where they are.

Don't make drill-through pages public in the report navigation. They should only be reachable via drill-through. Otherwise users land on them with no filters applied and see a giant unfiltered table.

The filter pane itself - format it properly

The default filter pane is functional but ugly. Spend ten minutes formatting it. Match the colour scheme of the report, set the font size, make the section headers readable. This is something users see constantly and it shapes their perception of report quality.

Also collapse it by default. The expanded filter pane takes up a lot of canvas real estate and most users don't need to see it most of the time. Collapsed it shows as a slim icon they can expand when needed.

Lock the filters you don't want users changing. The padlock icon makes a filter visible (so users see what's applied) but prevents them changing it. Useful for filters that scope the report to a specific context that shouldn't be changed.

Hide the filters that aren't relevant to consumers. If you've got a "Status != Deleted" filter that scopes out soft-deleted records, the user doesn't need to see it. Hide it from the filter pane. They get a cleaner experience and you keep the data hygiene.

Apply All Filters - turn it on for big reports

By default, every filter or slicer change triggers an immediate refresh of all visuals. For small reports that's fine. For large or DirectQuery-backed reports it's painful, because the user picks year, then quarter, then region, and the report re-queries three times.

The Apply All Filters option (in the filter pane settings) adds an Apply button. Users make all their selections, hit Apply, and the visuals refresh once. Much better experience for any report where queries take more than a second or two.

I'd default to having Apply All Filters on for any report with more than a handful of visuals or any DirectQuery model. The slight learning curve for users (they need to remember to hit Apply) is worth the performance benefit.

What about mobile

Filters on mobile are a separate design problem. The filter pane works on mobile but it's awkward. Slicers are better but they take up scarce vertical space.

The pattern that works best for mobile is two or three of the most important slicers at the top of a mobile-optimised page layout, plus the filter pane for power users who really need it. Don't try to replicate the desktop filter experience on a phone. Make the mobile experience deliberately simpler.

We do a lot of mobile app and mobile-optimised reporting work and the general principle holds across platforms: small screens demand fewer choices presented more clearly.

What I'd actually do

If I were designing a new Power BI report from scratch tomorrow, here's the filter approach I'd default to:

Three or four slicers across the top of every page for the primary dimensions. Synchronised across pages, formatted consistently.

Filter pane open with secondary filters visible. Apply All Filters turned on if the report has any meaningful query time.

Visual interactions reviewed and pared back. Most cross-filtering disabled, with one or two designated driver visuals.

Drill-through pages for detail views, with back buttons and clear context indicators.

Hard filters at page or visual level for scoping rules that shouldn't be user-changeable. Hidden from the filter pane.

That's it. Not complicated. The complication comes from authors who don't think about the experience and ship the defaults, then wonder why users complain.

Final thoughts

Filtering is the part of Power BI that users actually touch. Everything else (model design, DAX, refresh tuning) is invisible to them. The filter experience is the report, as far as they're concerned.

If you're getting complaints about confusing reports, look at filters first. Almost always that's the problem. The fix is usually a few hours of deliberate redesign, not a rebuild.

Microsoft's full guidance is at their filters and highlighting docs. The docs cover the features. This post is what I'd add about how to use them well.