The Types of Filters in Power BI Reports and When to Use Each

Most Power BI reports that go wrong don't go wrong because of bad DAX or an ugly chart. They go wrong because someone got confused about filters. A number on one page doesn't match the same number on another, an executive loses trust in the whole report, and three weeks later you're being asked why the dashboard "can't be relied on." Nine times out of ten the cause is a filter applied at the wrong level, or two filters quietly fighting each other.

So it's worth getting properly clear on the filter types Power BI gives you, because they are not interchangeable and the differences have real consequences. We build a lot of reporting for Australian businesses, and this is one of the first things we tighten up when we inherit a messy report. Let me go through the filter types, what each one is actually for, and the traps that catch people.

The filter pane and the three scopes

Open a report in Power BI Desktop or the service and you've got a Filters pane on the right. Most of the filtering people set up lives here, and it comes in three scopes that sit at different levels of the report.

Visual-level filters apply to a single visual and nothing else. You select a chart, you add a filter, and only that chart is affected. This is the most precise tool you have. If you want one table on the page to show only the top ten products by revenue while the chart next to it shows everything, a visual-level filter is how you do it.

Page-level filters apply to every visual on a single report page. Put a filter here and every chart, card, and table on that page respects it. This is the right home for context that defines the whole page. A page built specifically for the New South Wales sales team can carry a page-level filter for region equals NSW, and everything on it stays in that frame without you having to set the same filter on each visual.

Report-level filters apply to every visual on every page of the report. This is the broadest scope. If the whole report is meant to cover the 2026 financial year and nothing earlier, a report-level filter for that date range keeps the entire thing consistent. Set it once, and no page can quietly drift outside it.

The thing to hold in your head is that these stack. A visual inside a page inside a report is sitting under all three layers at once. That's powerful and it's also exactly where confusion creeps in, which I'll come back to.

Drillthrough filters

Drillthrough is the one a lot of report builders underuse, and it's genuinely one of the better features Power BI has.

The idea is you right-click a data point, say a particular customer or a single product, and jump to a separate detail page that's already filtered down to just that thing. The customer's whole order history, their payment behaviour, their support tickets, all on one page, scoped automatically to the customer you clicked.

You set this up by adding a field to the drillthrough area on the destination page. Power BI then offers the "drill through to" option wherever that field appears. Done well, it turns a flat dashboard into something people can actually explore. Click the underperforming region, land on a page that explains why, without building twenty near-identical pages by hand.

The honest catch is that people forget drillthrough exists because it's hidden behind a right-click. If your users don't know to right-click, the feature may as well not be there. We usually add a small visual cue or a bit of training so people actually find it. A great feature nobody discovers is wasted effort.

Cross-filtering and cross-highlighting

This is the behaviour that happens when you click a bar in one chart and the other visuals on the page react. It's automatic, it's driven by your data model relationships, and it's the thing that makes a Power BI report feel alive rather than static.

Click "Queensland" in a regional chart and the product breakdown next to it highlights or filters to Queensland. You control how this behaves through the visual interactions settings, where you decide whether one visual filters another, highlights it, or ignores it entirely.

Here's the opinion: most report builders never touch the interaction settings and just accept the defaults, and that's a mistake. The default cross-filtering is sometimes exactly wrong for the story you're trying to tell, and a couple of minutes setting which visuals talk to which can be the difference between a report that guides someone and one that confuses them. It's the cheapest polish you'll ever apply.

Slicers, which aren't filters but feel like them

Slicers deserve a mention because users think of them as filters even though, strictly, they're on-canvas visuals that filter the page.

A slicer is the dropdown or the set of buttons sitting on the report itself that lets the reader choose, say, a date range or a product category. The difference from the filter pane is that slicers are for your audience and the filter pane is mostly for you, the builder. A slicer is the control you hand to the reader. A page-level filter is the rule you set behind the scenes that they don't get to change.

Use slicers for the choices you want people to make themselves, and use the filter pane for the constraints you want enforced whether they like it or not. Mixing those up is a common reason reports feel either too rigid or too loose. We sort this distinction out early on most of the business intelligence work we take on, because it shapes how the whole report feels to use.

Filters you can lock, hide, and edit

A few more controls are worth knowing about because they change what your audience can do.

You can hide a filter so it still applies but the reader can't see or touch it. Handy when a filter is there for a good reason but you don't want to invite questions about it or let someone switch it off.

You can lock a filter so it stays visible but can't be changed. The reader sees the constraint, understands the report is scoped, but can't accidentally break it.

And you can control whether the filter pane is even visible to your audience at all. For a polished report going to executives, hiding the whole pane and giving them clean slicers instead often makes for a far better experience than exposing the builder's working underneath.

These small controls are the difference between a report that feels finished and one that feels like a work in progress someone forgot to clean up.

The traps that actually cause problems

Now the part that matters most, because this is where reports lose people's trust.

Stacked filters that contradict each other. Because visual, page, and report filters all apply at once, you can end up with a visual that's being squeezed by three different rules. A report-level date filter, a page-level region filter, and a visual-level top-N filter can interact in ways that aren't obvious when you're staring at the result. When a number looks wrong, check every scope, not just the one you remember setting. I've watched people spend an hour debugging DAX when the real culprit was a page filter someone added months ago and forgot.

The same metric reading differently across pages. This is the trust-killer. If "total revenue" says one thing on the summary page and something else on the detail page, it's almost always because the two pages carry different page-level filters. The fix is discipline: decide what's scoped at report level and leave it there, so shared numbers can't drift. When a number is meant to be the same everywhere, it should be filtered the same everywhere.

Filters quietly killing performance. Every filter is work the engine has to do. Pile enough of them on, especially complex ones on a large model, and your report slows down. If a report is sluggish, the filter setup is one of the first places to look, alongside the data model itself. This is exactly the kind of thing our Power BI consultants dig into when a client says their reports have become too slow to use in a meeting.

Forgetting what the audience can change. A filter you left editable is a filter a user will eventually change, then call you because "the report is broken." If a constraint must hold, lock it or hide it. Don't rely on people leaving it alone.

How to think about it

The simple mental model that keeps reports clean: filter at the broadest scope that's correct, and no broader.

If something should be true for the whole report, set it at report level once. If it's specific to a page, keep it on the page. If it's specific to a single visual, keep it on the visual. Hand your audience slicers for the choices they should make, and lock down the constraints they shouldn't. Set your visual interactions deliberately rather than accepting defaults.

Get that right and most of the "this report can't be trusted" conversations never happen, because the numbers are consistent by design rather than by luck.

If your reporting has reached the point where people argue about which number is correct instead of acting on it, that's usually a filtering and modelling problem we can sort out fairly quickly. Have a look at how we approach business intelligence, or get in touch and we'll take a look at what you've got.

Reference: Filters and highlighting in Power BI reports, Power BI documentation.