Three DAX functions account for a disproportionate share of measure errors in enterprise Power BI semantic models: ALL, ALLSELECTED, and ALLEXCEPT. Each controls a different aspect of filter context removal — the mechanism by which a DAX measure deliberately ignores some or all of the filters applied by slicers, report filters, and visual interactions before evaluating an expression. Choosing the wrong one produces measures that appear to work in test scenarios but fail silently in production, returning totals that do not match user expectations without generating any error. Understanding the precise behaviour of each function is not optional for any developer building production-grade DAX measures.

Filter Context: The Foundation You Must Understand First

Every DAX measure evaluates within a filter context — a set of filters that restrict which rows of data are visible to the formula engine at the moment of evaluation. Filter context accumulates from multiple sources: row context from calculated columns, cross-filter relationships between tables, slicers on the report page, report-level and page-level filters in the Filter Pane, and the visual's own grouping context (the row or column header values that define what each cell in a matrix or chart represents).

When a measure like SUM(Sales[Amount]) evaluates in a matrix visual, the filter context for each cell is the intersection of the visual's row value, the visual's column value, and any active slicers. The result is the sum of only the rows that pass all those filters simultaneously. ALL, ALLSELECTED, and ALLEXCEPT are all mechanisms for modifying that filter context before the aggregation runs — expanding the visible data beyond what the current filter context would normally allow.

"The difference between ALL, ALLSELECTED, and ALLEXCEPT is the difference between ignoring the entire audience, ignoring only the front row, and ignoring everyone except the people in the VIP section. Each is correct in a specific analytical context — and wrong in the others."

DAX ALL — Removing All Filters Completely

ALL removes every filter from a specified table or set of columns, regardless of where those filters came from. When used inside CALCULATE, it replaces the filter context for the specified objects with an unrestricted view of all rows in the table or all values in the column — as if no slicer, report filter, or visual grouping had been applied to those objects.

ALL accepts either a table reference ALL(TableName) or one or more column references — ALL(Table[Column1], Table[Column2]). When passed a table, it removes all filters on that entire table. When passed columns, it removes filters only on those specific columns, leaving filters on other columns in the same table active.

Primary Use Case: Percentage of Grand Total

The most common application is computing a percentage of grand total — where the denominator must represent the total across all values, regardless of how the visual is filtered.

Sales % of Total =
DIVIDE(
    SUM(FactSales[Sales]),
    CALCULATE(SUM(FactSales[Sales]), ALL('Sales Territory'[Sales Territory Country]))
)

In this measure, the denominator uses ALL on the Sales Territory Country column. Regardless of which country is selected in a slicer or shown in the current visual row, the denominator always returns the sum of sales across all countries. The numerator retains the current filter context, so each cell shows that country's sales as a percentage of the grand total across all countries.

Important Behaviour: ALL Also Works as a Table Function

Outside of CALCULATE, ALL used as a table function such as inside COUNTROWS(ALL(TableName)) — returns all rows of the table regardless of filter context. This is how it is used in row-count ratio measures. The key distinction is that inside CALCULATE, it acts as a filter modifier; outside, it acts as a table expression.

DAX ALLSELECTED — Respecting the Visual Filter Boundary

ALLSELECTED removes filters applied by the visual's own row and column context — the grouping that defines what each cell represents — while preserving filters applied by external sources: slicers, report-level filters, and page-level filters. The result is a denominator that represents the total of whatever is currently selected or visible in the report, rather than the absolute grand total of all data.

This distinction matters enormously for reports where users expect slicer selections to affect the percentage base. With ALL, selecting three countries in a slicer still shows each country's percentage of the global total — the slicer narrows the numerator but not the denominator. With ALLSELECTED, selecting those three countries recalculates the base to represent only those three countries, so the percentages sum to 100% within the slicer selection.

Sales % of Visible Total =
DIVIDE(
    SUM(FactSales[Sales]),
    CALCULATE(SUM(FactSales[Sales]), ALLSELECTED('Sales Territory'[Sales Territory Country]))
)

When a user filters to three countries in a slicer, this measure returns each country's share of the combined sales of those three countries — recalculating the base dynamically as the slicer selection changes. This is the correct pattern for subtotal percentages, relative rankings within a filtered view, and any analytical context where the percentage should always sum to 100% within the visible scope.

DAX ALLEXCEPT — Selective Filter Preservation

ALLEXCEPT removes all filters from a specified table except filters applied to columns explicitly listed in its arguments. It is the inverse of ALL(Table[Column1], Table[Column2]) — rather than specifying which columns to clear, you specify which columns to keep, and all other filters on the table are cleared.

The function signature is ALLEXCEPT(TableName, Column1, Column2, ...). The first argument is always the table; subsequent arguments are the columns whose filters should be preserved. All other filters on the table are removed.

Sales for Year (All Periods) =
CALCULATE(
    SUM(FactSales[Sales]),
    ALLEXCEPT(DateTime, DateTime[CalendarYear])
)

This measure removes all filters on the DateTime table except the CalendarYear filter. When a visual groups by both year and month, this measure returns the full-year total for each year across all months — the month context is cleared, but the year filter is preserved. This pattern is useful for creating year-level reference values that appear alongside monthly breakdowns without requiring separate date hierarchy measures for each level.

ALLEXCEPT vs ALL on Specific Columns

For tables with few columns,ALLEXCEPT and ALL on specific columns are often interchangeable ALLEXCEPT(DateTime, DateTime[CalendarYear]) produces the same result as ALL(DateTime[Month], DateTime[Quarter], DateTime[Week]...). ALLEXCEPT is more maintainable when the table has many columns, because adding a new column to the date table does not require updating the measure ALLEXCEPT automatically clears new columns unless they are explicitly listed as exceptions.

The Three Most Common Mistakes With These Functions

Using ALL when ALLSELECTED is needed for visual totals. A percentage-of-total measure built with ALL in a matrix visual will show percentages that do not sum to 100% when any slicer filter is active, because the denominator ignores the slicer. Report consumers find this confusing and often interpret it as a calculation error. If percentages should always be relative to the current visible scope, ALLSELECTED is the correct function.

Using ALLEXCEPT and expecting it to respect external filters.ALLEXCEPT removes all context filters on the specified table except those on the listed columns — including filters from slicers. If a user applies a slicer filter on a column that is not listed in the ALLEXCEPT exceptions, that slicer filter is cleared by the measure. This is frequently unexpected and produces measures that appear to ignore user selections. The fix is either to add the slicer column to the ALLEXCEPT exception list, or to reconsider whether ALLEXCEPT is the right function for that use case.

Passing a table to ALL inside CALCULATE and expecting column-level filters to survive.CALCULATE(SUM(Sales[Amount]), ALL(Sales)) removes every filter on the Sales table — including filters from related dimension tables that propagate into Sales through cross-filter relationships. If the intent is to clear only a specific column's filter, passing the column reference rather than the table reference is the correct approach.

ALL vs ALLSELECTED vs ALLEXCEPT: Decision Guide

Enterprise Measure Patterns Using All Three Functions

In a well-structured enterprise semantic model, all three functions have a regular place. A typical financial reporting model uses ALL in measures that compute ratios against a global base — such as each cost centre's spend as a percentage of total company spend, where the total must never change regardless of which cost centres are filtered. It uses ALLSELECTED in measures that power matrix visuals where the visual total row should represent only the rows visible in the current filtered view. And it uses ALLEXCEPT in time intelligence support measures that need to anchor a calculation to a specific level of the date hierarchy — year, quarter, or month — while clearing sub-level detail filters.

The patterns become compound in complex models. A year-to-date percentage-of-target measure might use for the target denominator (to respect territory slicer selections) while using ALLEXCEPT on the date table (to clear day and week filters while preserving the year and quarter context). Building these patterns correctly requires a clear mental model of which filters exist in the current evaluation context and which of them the measure should ignore. For enterprise Power BI consulting engagements, DAX filter context is consistently the area where the most impactful model quality improvements are found.

Next Steps for DAX Mastery

Mastering DAX ALL, ALLSELECTED and ALLEXCEPT is the entry point to a broader set of filter context manipulation patterns in Power BI — including REMOVEFILTERS (a more explicit alternative to ALL in some contexts), KEEPFILTERS, and the full range of CALCULATE filter arguments. The mental model to develop is not a memorised list of functions, but a precise understanding of what filter context exists at each point in a measure's evaluation, and which parts of it should be modified before the aggregation runs.

For teams building enterprise-grade semantic models — where measures must behave correctly across all combinations of slicer filters, report filters, drill hierarchies, and matrix visual structures — speak with a certified Power BI developer at Numlytics. We work with data and analytics teams across the US, UK, Australia, and UAE to design semantic models with DAX measures that are robust, maintainable, and performant under real enterprise usage patterns.

For a related look at how DAX user-defined functions can package and reuse filter logic across a model, see our post on DAX user-defined functions in Power BI. And for the broader semantic model architecture that these measures live in, see our guide on TMDL scripting in Power BI.