← All Kits · Power BI Kit

Filters, Slicers and Visual-Level Filters: Which One Is Changing Your Number

Michael Nocito · Updated August 2026 · Every number on this page was worked before it was published

Two cards on the same page, both meant to show revenue, showing different numbers. Nothing is broken. One of them has a visual-level filter that only shows in the Filters pane when that specific visual is selected.

What you do: learn the five places a filter can live, and put the filter state on the page in words so a reader can check it.

The short version. Every filter applies at once, and the result is the intersection of all of them.

The five places

Plus two more that behave like filters and catch people out: cross-filtering from clicking another visual, and row-level security, which changes what a specific user can see without appearing anywhere at all. See row-level security.

They do not apply in an order

The common mental model is a pipeline: report filter first, then page, then visual. It is the wrong picture and it leads to wrong predictions. All the filters combine into a single filter context, and a row survives only if it satisfies every one.

So a report-level filter of Region equals North and a visual-level filter of Region equals South produce an empty visual, not South and not North. There is no override, only intersection.

The one thing that can override is DAX. CALCULATE with ALL or REMOVEFILTERS deliberately discards part of the incoming context, which is exactly how a percent-of-total measure keeps its denominator while the numerator is filtered:

Share of total =
DIVIDE(
    SUM(Sales[Amount]),
    CALCULATE(SUM(Sales[Amount]), REMOVEFILTERS(Region))
)

Making the filter state visible

A report that states its own filters is a report people trust, and it survives being screenshotted into an email, which is how most numbers travel.

Filter state =
VAR r = SELECTEDVALUE(Region[Region], "All regions")
VAR d = MIN('Date'[Date]) & " to " & MAX('Date'[Date])
RETURN r & "  |  " & d

Put that in a card at the top of the page. For a multi-select slicer, CONCATENATEX(VALUES(Region[Region]), Region[Region], ", ") lists what is chosen.

Choosing which mechanism to use

The second row is worth arguing for. Rows that should never be reported on do not belong in the model at all. Filtering them out in Power Query means no report can accidentally include them, and the model is smaller. A report-level filter is one unticked box away from failing.

Debugging a number you do not believe

1. Select the visual and open the Filters pane. Read all four sections, top to bottom.
2. Check Edit Interactions from every slicer on the page.
3. Look for a Top N filter, which hides rows without removing them from the total.
4. Open the measure and look for CALCULATE, ALL, REMOVEFILTERS or FILTER.
5. Check whether row-level security applies to you, by using View as Role.
6. Use Performance Analyzer to copy the DAX the visual actually ran, and run it in DAX Studio. That is the ground truth.

How to apply this to your own work

1. Add a filter-state card to your most-shared page this week.
2. Audit the Filters pane on every page and remove filters that duplicate a Power Query step.
3. Write page-level filters into the page title, so a screenshot carries its own scope.
4. Check Edit Interactions across the report once. It is usually where the surprising behaviour lives.
5. Move permanent exclusions upstream into the query, where they cannot be untocked.

The one habit to keep

Ask what rows this number is over, and be able to point at where that was decided. If the answer is inside a measure or in a pane nobody opens, put it on the page.

Could a reader of your main page tell you what is filtered, from the page alone?