ALL vs ALLEXCEPT vs ALLSELECTED vs REMOVEFILTERS in DAX
ALL vs ALLEXCEPT vs ALLSELECTED vs REMOVEFILTERS in DAX
These four functions are the "filter removers" of DAX. They all strip filter context, but they strip different filters. Use the wrong one and your "% of total" looks fine in testing and is quietly wrong in production. Let's nail the differences with a NovaMart sales dataset.
Base measure for everything below:
Total Sales = SUM(Sales[Amount])
ALL: remove everything
ALL removes filters from a table or column. It gives you the value as if no filter existed on that field at all, ignoring slicers, ignoring the visual's rows.
Pct of Grand Total =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALL(Sales))
)
The denominator is the absolute grand total of the whole Sales table, no matter what the user has clicked. ALL(Sales) wipes all filters on Sales. You can also target one column:
Pct of All Cities =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALL(Sales[City]))
)
Here only the City filter is removed; a Category slicer still applies. Each row's sales divided by the total across all cities (for the selected category).
ALL also has a second job: as a table function it returns a table with all filters stripped, handy as the source for iterators.
REMOVEFILTERS: ALL, but it reads better
REMOVEFILTERS was introduced to do exactly what ALL does as a CALCULATE modifier, but with a name that says what it means. Functionally, for filter removal inside CALCULATE, these are identical:
Pct of Grand Total =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], REMOVEFILTERS(Sales))
)
Difference in practice:
- Use
REMOVEFILTERSwhen you only want to clear filters. It cannot be used to return a table. - Use
ALLwhen you need the removed-filter table as an argument toSUMX,FILTER, etc.
For readability, prefer REMOVEFILTERS inside CALCULATE. Future-you reading the measure will thank you.
ALLEXCEPT: remove everything except what you list
ALLEXCEPT removes all filters on a table except the columns you protect. This is the right tool for "subtotal per group" patterns.
Say you want each row's share within its state, across all cities in that state:
Pct within State =
DIVIDE(
[Total Sales],
CALCULATE(
[Total Sales],
ALLEXCEPT(Sales, Sales[State])
)
)
The denominator clears every filter on Sales except State. So Mumbai and Pune rows (both Maharashtra) share the same denominator: total Maharashtra sales. This is the clean way to compute "% of state total" without hardcoding anything.
Watch out: ALLEXCEPT keeps the listed columns and removes everything else, including filters you forgot about. If a Category slicer is active, ALLEXCEPT(Sales, Sales[State]) removes it. If you want category respected too, list it.
ALLSELECTED: respect the slicers, ignore the visual rows
This is the one that makes percentages feel "smart". ALLSELECTED removes filters coming from inside the visual (the row/column context) but keeps filters the user applied via slicers and the outer query.
Pct of Visible Total =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALLSELECTED(Sales[City]))
)
Scenario: a user slices the report to "South region" with 4 cities. With ALL, the denominator is all cities in India, so the percentages don't add to 100% in the visual. With ALLSELECTED, the denominator is the total of just those 4 visible cities, and the column sums to a tidy 100%. That is almost always what business users expect from a "% of total" on a filtered report.
Quick comparison
| Function | Removes visual row filter | Removes slicer filter | Returns a table |
|---|---|---|---|
ALL | Yes | Yes | Yes |
REMOVEFILTERS | Yes | Yes | No |
ALLEXCEPT | Yes (except listed cols) | Yes (except listed cols) | Yes |
ALLSELECTED | Yes | No | Yes |
Which one is correct?
- Grand total denominator, ignore everything ->
ALLorREMOVEFILTERS. - Share within a group (state, category) ->
ALLEXCEPT, protecting the group column. - Percentages that add to 100% inside a filtered report ->
ALLSELECTED.
Common pitfalls
1. Using ALL for a "% of total" that should respect slicers. Users filter to one region, see percentages that don't sum to 100%, and file a bug. Switch to ALLSELECTED.
-- Often wrong on filtered reports
DIVIDE([Total Sales], CALCULATE([Total Sales], ALL(Sales[City])))
-- Usually what they wanted
DIVIDE([Total Sales], CALCULATE([Total Sales], ALLSELECTED(Sales[City])))
2. ALLEXCEPT dropping a filter you needed. Remember it removes everything except what you list. Be explicit: ALLEXCEPT(Sales, Sales[State], Sales[Category]) if both matter.
3. ALLSELECTED in measures used outside visuals. Its behaviour depends on the surrounding query (the "shadow filter context"), so the same measure can return different results in a card versus a matrix. Test it where it'll actually live.
4. Reaching for ALL(Sales) when you meant a column. ALL(Sales) nukes filters on the entire table. If you only meant to free up City, use ALL(Sales[City]). Over-removing changes your denominator.
Best practice
Write the denominator measure separately and name it honestly:
Denominator (Visible Cities) =
CALCULATE([Total Sales], ALLSELECTED(Sales[City]))
Pct of Visible Total =
DIVIDE([Total Sales], [Denominator (Visible Cities)])
Self-documenting measures are how you avoid the silent percentage bugs that plague Power BI reports. Pick the remover that matches the business question, not the one you typed first.
Related: What is DAX and Why It Matters · Practice Power BI
Don't just read. Prove your skill on DevWithData.
Shashikant
· Founder, DevWithDataData professional and Power BI instructor. Building DevWithData to help analysts prove their skills, not just collect certificates.
Reading is not enough. Prove your skill.
DevWithData measures your actual ability with the Data Readiness Index. Stop reading — start practicing.
Continue Learning
CALCULATE in Power BI: The Complete Guide with Examples
CALCULATE is the single most important function in DAX, and also the most misunderstood. This guide breaks down exactly what CALCULATE does to filter context, how filter arguments replace existing filters, when to reach for KEEPFILTERS, and how to write measures you can trust. Includes real, copy-paste DAX measures built on Indian retail and UPI datasets, plus the pitfalls that trip up most learners.
9 min readDAX Time Intelligence: The Complete Guide (YTD, MTD, QTD)
Time intelligence is where Power BI dashboards earn their keep, and where most break. This guide covers TOTALYTD, TOTALMTD and TOTALQTD, the non-negotiable date table requirement, marking it as a date table, and how to handle the Indian fiscal year that starts in April. Includes real, copy-paste DAX measures on Indian sales data and the pitfalls that silently return blanks.
8 min readPL-300 Exam-Day Tips & Practice Strategy
You have studied the four PL-300 domains, but the exam is also a test of time management and nerves. This guide gives Indian candidates a concrete plan: how the 100-minute exam is structured, the question types you will face (drag-drop, case studies, build-from-scratch), a 4-week mock-exam schedule, and the exact-day routine that stops you from running out of time on the case study at the end.
8 min read