Home|Blog|ALL vs ALLEXCEPT vs ALLSELECTED vs REMOVEFILTERS in DAX
Sign in →
power-bi
dax
all
allselected
filter-context

ALL vs ALLEXCEPT vs ALLSELECTED vs REMOVEFILTERS in DAX

By Shashikant·29 June 2026·4 min read

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 REMOVEFILTERS when you only want to clear filters. It cannot be used to return a table.
  • Use ALL when you need the removed-filter table as an argument to SUMX, 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

FunctionRemoves visual row filterRemoves slicer filterReturns a table
ALLYesYesYes
REMOVEFILTERSYesYesNo
ALLEXCEPTYes (except listed cols)Yes (except listed cols)Yes
ALLSELECTEDYesNoYes

Which one is correct?

  • Grand total denominator, ignore everything -> ALL or REMOVEFILTERS.
  • 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.

DevWithData

Shashikant

· Founder, DevWithData

Data 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