DAX calculations execute within two distinct evaluation contexts that determine how expressions are resolved. Filter context is the set of active filters applied to the data model at the time a measure evaluates — the combination of report page filters, slicer selections, visual-level filters, and measure-level CALCULATE filters that together determine which rows of each table are visible. When a user selects “Saudi Arabia” in the Entity slicer and “Q1 2025” in the Period slicer, those selections establish the filter context for every measure on the page — each measure evaluates its aggregation over only the rows that satisfy both filter conditions. Row context is the current row being processed by an iterator function (SUMX, AVERAGEX, FILTER, MAXX) or evaluated in a calculated column — at each iteration step, the expression is evaluated in the context of the current row’s values, with access to each column’s value for that specific row.
Filter Context vs Row Context: Practical Comparison
| Context Type | Established By | Accesses | Example |
|---|---|---|---|
| Filter Context | Report slicers; page filters; visual filters; CALCULATE; relationships | Aggregated values across filtered rows — SUM, COUNT, AVERAGE | Total revenue for selected entity and period |
| Row Context | Calculated column definition; iterator function (SUMX, FILTER) at each row | Individual column values for the current row | Gross margin % calculated per row in a calculated column |
Why the Distinction Matters for Finance Developers
The distinction matters in two specific scenarios that are common in finance Power BI models. First, calculated columns vs measures: a calculated column is evaluated in row context (it has access to each row’s column values but no filter context from the report); a measure is evaluated in filter context (it aggregates across the filtered row set but has no direct row access without an iterator). A developer who tries to write a calculated column that references a measure will find that the measure evaluates without the report’s filter context — because calculated columns are computed at data refresh time, when no report filters exist. Second, CALCULATE inside iterators: when CALCULATE is used inside SUMX or another iterator, it transitions the current row context into a filter context — making the current row’s values act as filters for the CALCULATE expression. This context transition is what makes SUMX(Table, CALCULATE([Measure])) different from plain SUMX(Table, [Measure]).
Context in Relationship Propagation
Filter context propagates through relationships in the data model — a filter on the Entity dimension table automatically filters all fact tables connected to it through active relationships, without any explicit filter specification in the measure. Row context does not propagate through relationships automatically; accessing related table values in row context requires the RELATED function. This asymmetry is the source of a common DAX error: a developer in a SUMX iteration tries to access a value from a related dimension table using column syntax rather than RELATED, and receives an error because the related table’s values are not in row context.
What Goes Wrong in Practice
The most frequent filter-context vs row-context confusion error in production finance Power BI models is a measure written with the assumption that the measure’s execution context carries row-level information about each row of a table — attempting to reference a column value (like [Entity Name]) directly in a measure rather than through a SELECTEDVALUE, VALUES, or iterator. Measures do not have row context; they have filter context. A measure that tries to reference [Entity Name] directly will return an error unless SELECTEDVALUE or an iterator is used to resolve a single row value from the filter context.
How Loop Wise Solutions Trains on This
In our Power BI developer training and code review processes, filter context vs row context understanding is the first competency assessment — every DAX measure reviewed for production deployment must be accompanied by an explanation from the developer of what filter context the measure expects and how it handles multi-row selection scenarios. Measures that behave correctly for single-selection scenarios but fail for multi-selection scenarios almost always reflect an incorrect assumption about filter or row context.
Answers before you ask.
Filter context defines which rows of a table are visible to a calculation, set by report slicers, filters, and CALCULATE. Row context is the current row being processed — in an iterator function or a calculated column. Filter context is about what is filtered; row context is about which single row is being evaluated right now.
Filter context comes from the report environment — slicers, visual filters, page filters — and from explicit CALCULATE arguments. Row context arises inside iterators (like SUMX) and in calculated columns, where DAX processes one row at a time. Knowing which context a calculation is running in is the starting point for reasoning about its result.
Through context transition: when CALCULATE runs inside a row context, it converts that row context into a filter context, so the current row's values become filters. This bridge is why measures behave differently inside iterators than outside them. Understanding this transition is the conceptual foundation for all non-trivial DAX development.
Because a calculation's result depends entirely on which context governs it. Expecting filter-context behaviour where row context applies — or forgetting that CALCULATE triggers context transition — yields measures that return plausible but wrong numbers. Most subtle DAX bugs trace to a misunderstanding of which context is in effect and how it changes.