Why Your Power BI Measure Ignores the Slicer

By the XLsheetAI Team · Updated August 14, 2026 · 9 min read

The one-sentence answer

Your measure is not stuck — something in it is deliberately ignoring the filters the visual is passing down, and in nine cases out of ten that something is an ALL sitting inside a CALCULATE. Understanding why requires one idea, filter context, and that idea explains most of the DAX behaviour that looks arbitrary from the outside.

A measure is not a value, it is a recipe

This is the mental shift that makes DAX click. A measure does not hold a number. It holds an instruction that gets re-executed for every single cell it appears in, and each execution sees a different set of filters.

Put Total Sales in a card and it runs once, against whatever the page filters allow. Put the same measure in a table sliced by region and it runs once per row — the North row runs it with a North filter applied, the South row with South. Same measure, different answers, because the surrounding filters differ.

That surrounding set is the filter context, and it is assembled from everything filtering the cell at once: slicers, the row and column headers of the visual, page and report level filters, cross-filtering from other visuals, and anything a CALCULATE in the measure itself adds.

The usual culprit: ALL inside CALCULATE

Here are two measures over the same column:

Total Sales = SUM(Sales[Amount])

All Sales = CALCULATE(SUM(Sales[Amount]), ALL(Sales))

ALL(Sales) means "evaluate this as if no filters existed on the Sales table". The second measure therefore returns the grand total in every row, in every visual, no matter what anyone clicks.

That is correct and useful when you are building a denominator — a percentage of total needs a total that does not shrink as the numerator does. It is wrong, and confusing, when you copied it from a blog post and expected it to follow the slicer.

The related functions behave the same way with narrower aim. REMOVEFILTERS is a clearer synonym for ALL in this role. ALLEXCEPT(Sales, Sales[Region]) strips every filter except the one on Region, which is how you compute "total for this region regardless of product or date".

CALCULATE: the only function that changes context

Everything else in DAX reads the filter context. CALCULATE is the one function that rewrites it before the calculation runs. Its first argument is the expression; every argument after that is a filter.

North Sales = CALCULATE(SUM(Sales[Amount]), Sales[Region] = "North")

Crucially, this replaces the existing filter on Region rather than adding to it. Slice the page to South and this measure still reports North. That is deliberate design — it is how you build "this year vs last year" comparisons — but it is also why a measure someone else wrote can seem to ignore your slicer entirely.

When you want your filter to narrow the existing one rather than override it, wrap it:

North Sales = CALCULATE(SUM(Sales[Amount]), KEEPFILTERS(Sales[Region] = "North"))

Now slicing to South returns blank, because nothing is both North and South — which is usually the honest answer.

ALL vs ALLSELECTED, in plain terms

% of Visible Total =
DIVIDE(
    SUM(Sales[Amount]),
    CALCULATE(SUM(Sales[Amount]), ALLSELECTED(Sales))
)

If a stakeholder has ever asked why the percentage column does not add up to 100, this is the answer: the denominator was built with ALL when it should have used ALLSELECTED.

The other reason a number never moves

Before debugging the DAX, confirm the thing is a measure at all. A calculated column is computed once when the model refreshes and stored on disk for every row. It exists long before any report does, and it has no access to filter context whatsoever.

Written as a column, a formula that should have been a measure does not error. It returns a plausible-looking value that never changes, which is the most expensive failure mode in Power BI because it survives review. The test is one question: should this number change when someone clicks a slicer? If yes, it must be a measure.

A three-step debugging order

1. Is it a measure or a calculated column? Columns cannot react to anything. This catches more cases than the other two combined.
2. Is there an ALL, ALLEXCEPT or REMOVEFILTERS in it? If so, it is discarding context on purpose. Decide whether ALLSELECTED is what you actually meant.
3. Is a CALCULATE filtering the same column you are slicing on? If it is, the measure's filter wins and your slicer is being overridden. Add KEEPFILTERS if you want both to apply.

If all three check out and the number is still wrong, look at the relationship between the tables. A measure filtered through a relationship that points the wrong way, or one that is inactive, produces the same "nothing happens" symptom for a completely different reason.

DAX not behaving? Paste a measure into XLsheetAI and get a plain-English explanation of what it filters and why, or describe the calculation you want and get the DAX — including whether it should be a measure or a column.

Bottom line

A measure that will not move is a measure whose context has been removed. Look for ALL first, for a CALCULATE overriding your slicer column second, and check it is not a calculated column before either. Reach for ALLSELECTED whenever the answer should reflect what the user can actually see.

Related reading: Excel to DAX formula guide covers the row-context-versus-filter-context shift in full, and Excel vs Power BI covers when a model is worth building at all.