Applying CALCULATE([Measure], ALL('Table')) in DAX only strips filters from the specified table in the filter context, but it doesn’t guarantee you’re working in a “no filter” vacuum—especially when visual-level or slicer filters are involved. By the end of this article, you’ll know why some filters remain stubbornly in effect, why ALL is only part of the solution, and how to explicitly clear even the filters you didn’t realize were still there.
ALL Doesn’t Clear Everything: The Hidden Persistence of Visual-Level Filters
Most developers expect CALCULATE([Measure], ALL('Table')) to “remove all filters” on 'Table'. But the reality is more nuanced: ALL removes filters only from the columns of the specified table, and only in the filter context—not from every possible source of filtering, and not from unrelated tables or shadow filter context maintained by visuals.
- ALL(‘Table’) removes filters on columns of
'Table'in the current filter context. - It does not clear filters from unrelated tables, nor does it always neutralize filters introduced by the visual’s axes or slicers that act through relationships.
- Filters applied via slicers or visual axes can persist through relationships even after
ALL—especially when using star schemas or when dimensions are involved.
The root of the confusion is that filter context in DAX is cumulative and can be layered from multiple sources: row context, explicit filters in CALCULATE, the visual’s own context (the “shadow” filters), and implicit filters from slicers or drillthrough.
Counterintuitive Result: ALL Fails to Escape Visual Slicers
Take a matrix visual with Dim_Product[Category] on rows and a slicer for Dim_Date[Year]. You write:
Total Sales (Ignore Product Filter) :=
CALCULATE([Total Sales], ALL(Dim_Product))
You expect this measure to return the same value for every row in the matrix, as if the product category is not filtered. But each cell still reflects the Dim_Date[Year] slicer, and—crucially—the matrix’s current Category context. ALL(Dim_Product) wipes only the filters on Dim_Product, not on Fact_Sales, nor does it touch filters from other tables, nor the visual context itself.
ALLSELECTED and the Shadow of Visual Context
ALLSELECTED is often misapplied as a fix when ALL doesn’t do what you hope. But ALLSELECTED reconstructs the filter context as it appears after user selections, including slicers and visible rows/columns in the visual. This makes it even more likely to preserve slicer or visual axis filters.
Total Sales (ALLSELECTED) :=
CALCULATE([Total Sales], ALLSELECTED(Dim_Product))
This measure will still reflect the slicer and the matrix’s current row. The “shadow” filter context of the visual—what’s been selected, expanded, or cross-filtered—remains. ALLSELECTED is designed for percent-of-total or subtotal logic that honors user selections, not for “ignore everything and give me the grand total.”
Escaping All Filters: The Role of REMOVEFILTERS and Explicit ALL
If you want to strip all filters—including those from slicers, visual axes, and related tables—you need to explicitly remove them. REMOVEFILTERS (or ALL applied to every relevant table) will clear filters more broadly, but only for the columns or tables you name. DAX will not automatically clear filters from related tables unless instructed.
Worked Example: Removing All Date and Product Filters
Take a model with:
Fact_Salesfact tableDim_Productdimension (one-to-many to Fact_Sales on ProductKey)Dim_Datedimension (one-to-many to Fact_Sales on DateKey)
Your visual: a matrix with Dim_Product[Category] on rows, Dim_Date[Year] as a slicer.
[Total Sales] := SUM(Fact_Sales[SalesAmount])
You want a grand total, ignoring both product and date filters, regardless of the slicer or matrix axis. The naive approach:
[Total Sales (ALL Product)] :=
CALCULATE([Total Sales], ALL(Dim_Product))
This fails: each matrix row still respects the Dim_Date[Year] slicer, and the Category row context is cleared but Fact_Sales is still sliced by whatever filters from Dim_Date are present.
What actually clears all visual and slicer filters?
[Total Sales (Ignore Product & Date)] :=
CALCULATE(
[Total Sales],
REMOVEFILTERS(Dim_Product),
REMOVEFILTERS(Dim_Date)
)
Or equivalently, using ALL:
[Total Sales (Ignore Product & Date)] :=
CALCULATE(
[Total Sales],
ALL(Dim_Product),
ALL(Dim_Date)
)
This measure now ignores all filters—whether from slicers, visual axes, or drillthrough—on both Dim_Product and Dim_Date. The grand total appears in every matrix row, regardless of user interaction with slicers or the matrix itself.
What About Relationships and Other Tables?
If your filters arrive via bridge tables or relationships (e.g., a many-to-many pattern, or a filter on Dim_Region that flows to Fact_Sales), you must explicitly clear those as well. DAX is strictly literal: only the tables you name have their filters removed. There is no “super ALL” function that wipes the slate of all filter context everywhere in the model.
The Trap of Variables: Why Measures Sometimes “Remember” a Filter You Thought Was Gone
Variables (VAR) in DAX can capture a value at a specific context, which may include filters you later try to remove. If you define a variable before removing filters in CALCULATE, the variable is evaluated in the original filter context, not the new one. This bites especially hard in time intelligence and ratio calculations.
Wrong Grand Total :=
VAR SalesAtSelection =
[Total Sales]
RETURN
CALCULATE(
SalesAtSelection,
ALL(Dim_Product),
ALL(Dim_Date)
)
This looks plausible, but SalesAtSelection is evaluated before CALCULATE alters the filter context, so it still contains the original filters. The result: you see a subtotaled value, not the true grand total.
The fix: move the calculation inside CALCULATE so context transition applies:
Right Grand Total :=
CALCULATE(
[Total Sales],
ALL(Dim_Product),
ALL(Dim_Date)
)
Or, if you need to use a variable, define it after the filter context is changed:
Right Grand Total with VAR :=
CALCULATE(
VAR Total := [Total Sales]
RETURN Total,
ALL(Dim_Product),
ALL(Dim_Date)
)
Calculation Groups: Why They (Often) Don’t Rescue You from Visual Filters
Calculation groups in Tabular models (now natively supported in Power BI Desktop as of recent versions) let you apply reusable logic across measures. But calculation group items, like measures, operate in the current filter context unless they explicitly remove or alter it. Applying ALL or REMOVEFILTERS inside a calculation group is subject to the same limitations: you must name every table whose filters you wish to ignore.
Worked Example: Calculation Group for “Ignore All Filters”
Suppose you define a calculation group item called “Grand Total”:
// Calculation group DAX formula for "Grand Total"
CALCULATE(
SELECTEDMEASURE(),
REMOVEFILTERS(Dim_Product),
REMOVEFILTERS(Dim_Date)
)
If a user applies a filter from another related dimension (e.g., Dim_Region), the calculation group does not automatically clear it. You must keep the calculation group’s logic in sync with the actual ways your data can be sliced—otherwise, “Grand Total” may still reflect filters you thought were excluded.
Actionable Takeaways: Know What Filters You’re Removing—And Which Remain
- ALL(‘Table’) only removes filters from the named table, not from all tables in the filter context.
- Visual-level filters, slicers, and axes can still filter your data through relationships unless you explicitly clear those tables as well.
- REMOVEFILTERS and ALL are functionally equivalent for filter removal, but both require exhaustive listing of every table to escape all context.
- Variables capture the filter context at their point of definition. If you need a value in a “cleared” context, define the variable inside CALCULATE or after filters are removed.
- Calculation groups don’t magically ignore all filters—your logic must enumerate every relevant table or column whose filters should be cleared.
If you need a grand total that truly ignores all user selections, enumerate every dimension (and bridge) table whose filters could reach your fact table. Otherwise, you’ll always be working in the shadow of invisible filters.