⚡️🗒️Power BI: Context [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[DAX] Context

• {def} the set of data that a calculation, visual, or DAX expression evaluates at a given moment
• determines which rows are considered when a calculation is evaluated
• the same measure can return different results depending on the context
• enables users to perform dynamic analysis [5]
• used by measures, calculated columns/tables, iterator functions, slicers & filters, relationships, time intelligence, RLS, etc.
• can make it difficult to troubleshoot formulas [5]
• {concept} evaluation context
• {def} the set of conditions and rules that determines which data is used when a DAX formula calculates a result
• both the row context and the filter context contribute to the evaluation context [3]
• the two are very different, serving different purposes, having different features and different behaviors [3]
• {type} filter context
• {def} the set of filters that are active when a calculation is evaluated
• determines which rows of data are visible to a measure at any given moment [2]
• added when a filter constraint is applied on the set of values allowed in a column or table, by using arguments to a formula [5]
• applies or removes filters to/from tables in the semantic model [2]
•  filters tables in a model [2]
•  propagates filters through relationships [2]
•  managed by CALCULATE [2]
• sources
• visuals (charts, tables, cards, etc.)
• slicers
• report/page filters
• cross-filtering from other visuals
• DAX functions
• e.g. CALCULATE(), CALCULATETABLE()
• {type} row context 
• {def} the context in DAX where an expression is evaluated for a single row at a time, giving DAX access to the values of the current row
• aka 'the current row' 
• used when Power BI is evaluating one row at a time [1]
• needed to obtain the value of a column for a certain row [2]
•  {warning} trying to access the value of a column in a measure without an active row context results in an error [2]
• exists whenever we create a calculated column or whenever we are computing an expression inside an iteration [2]
• calculated columns have an automatic row context [2]
• the row context for a formula includes the values from all columns in the current row [
• automatically follows the relationships between tables to determine which rows in related tables are associated with the current row [5]
• functions that iterate calculations over a table can have multiple current rows and current row contexts [5]
•  can be created formulas that recurse over an inner and outer loop [5]
• certain functions store the row context from the operation that preceded the current operation [5]
• e.g. EARLIER 
• the function stores two sets of context in memory [5]
• one set of context represents the current row for the inner loop of the formula [5]
• another set of context represents the current row for the outer loop of the formula [5]
• measures don't have a row context [2] 
• if is needed to evaluate an expression row by row inside a measure, is needed to start an iteration to create a row context [2]
• when using iterators, the developer is responsible for creating and handling the row context [2]
• iterates over a table and evaluate its column values [2]
• ⇐ one row at a time
• row context is the result of iterating over rows
• row context equals iteration [2] is not exactly a correct statement
• means that DAX evaluates expressions one row at a time
• during the iteration, DAX creates a row context that gives the formula access to the values of the current row
• functions like SUMX and calculated columns rely on this behavior
• the two aren't identical 
• iteration refers to the process of moving through rows
•  row context is knowledge of the current row during that process
• DAX creates a row context for the current row
• functions like a cursor [2]
• during an iteration, it points to a specific row of the table being iterated, telling the DAX formula which row is currently to be considered [2]
• it does not filter [2][3]
• it simply indicates to DAX which row is currently responsible for providing the values to perform the calculation and where the result of the calculation should go [3]
• it's irrelevant whether a column in the table is used in a particular calculation [3]
• all columns of the table are part of the row context when a calculation is performed [3]
• encountered when (aka created via)
• calculated columns
• the formula defines a calculated column [2]
• iterators 
• perform active iteration over a table [2]
• e.g. SUMX, FILTER, ADDCOLUMNS, etc.
• scans the table row by row, and during the iteration, the row context points to the current row [2]
• the row context is needed to obtain the value of a column for a certain row [2]
• iterator functions create row context while moving through rows
• help create multiple nested row contexts [2] 
• increases the complexity of the code [2]
• can transform into filter context through a mechanism called context transition [3]
• defines the value of a column by providing the exact row [2]
• calculated columns are always executed in a row context [2]
• is not the case for measures [2]
• {limitation} doesn't propagate filters through relationships from one table to another [2]
• {recommendation} use RELATED and RELATEDTABLE to direct and move the row context from one table over to another [2]
• {limitation} does not place any filter [2]
• {concept} context transition 
• occurs when a row context is converted into a filter context [1]
• takes any active row context and transforms it into a filter in the filter context [3]
• requires an active row context [2]
• either CALCULATE is executed or a measure is invoked [2]
• implies a context transition in these conditions [2]
• the row context is transformed into an equivalent filter context [2]
• usually the context transition happens because a measure is being invoked rather than because of an explicit CALCULATE [2]
•  leveraging the context transition leads to better code [2]
• without context transition DAX can only see the current row
• with context transition, DAX can use values from the current row to filter entire tables and compute aggregations
• the process is automatically execute by CALCULATE and CALCULATETABLE [2]
• any statement invoking either of these two functions performs a context transition [2]
• this happens regardless of whether [2]
• the functions functions were written explicitly [2]
• CALCULATE or CALCULATETABLE is used explictely [2]
• a function that conveniently hides CALCULATE or CALCULATETABLE functions from users but still invokes them [2]
• e.g. TOTALYTD
• this happens in calculated columns, whenever [2]
• a row context is present
• a function that iterates over multiple values is used (aka iterators)
• SUMX
• [measures] whenever a measure is invoked, the context transition happens immediately before the measure starts being executed, as if CALCULATE automatically surrounds the measure [2]
• {benefit} opens new ways to optimize the code [2]
• eliminates complex lookup logic
• reduces repeated filtering
• leverages relationships
• enables reusable measures
• improves performance with the storage engine
• pushes work toward the VertiPaq storage engine
• ⇐ highly optimized for aggregations
• {concept} visual calculation [>>]
• {def} DAX calculation that runs directly on a specific visual (table, matrix, chart, etc.) [3]
• {concept} visual calculation context
• context used by visual calculations, where calculations are performed after the visual has already been built
• uses the rows and columns that are visible in the visual itself rather than directly querying the underlying model
• allows users to calculate running totals, moving averages, differences, rankings, and other analyses directly within a visual 
• {recommendation} begin/experiment with simple formulas and relationships to see how context works [5]
• fastest ways to understand how evaluation context actually works
• helps to isolate context behavior 
•  many challenges are related to relationships
• {recommendation} learn filter context before row context
•  filter context appears in  in almost every advanced DAX solution later 
• {recommendation} predict before you run
• discoveries/knowledge results especially when the result differs from expectations
• {recommendation} use simple/small examples
• facilitates review and troubleshooting
• {recommendation} build a playground for learning 
• an experimentation model can prove valuable over time
• {recommendation} use DAX Studio early
•  it allows to inspect query plan, view filter context, analyze storage engine vs formula 
•  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"

[4] Microsoft Learn (2026) Modify DAX filter context in semantic models [link]

[5] Microsoft Support (202?) Context in DAX Formulas [link]

 

Resources:  

[R1] Microsoft Fabric Community Row vs Filter Context: a Visual Guide [link] 

 

Acronyms:
DAX - Data Analysis eXpressions

RLS - Row Level Security

 

⚡️🗒️Power BI: ALLSELECTED in DAX [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 13-Oct-2026

[DAX] ALLSELECTED()

• {def} function that returns all the rows in a table, or all the values in a column [1]
• ignores any filters that might have been applied inside the query [1]
•  removes the corresponding filters from the filter context, restoring the last shadow filter context
• keeps filters that come from outside [1] 
• gets the context that represents all rows and columns in the query, while keeping explicit filters and contexts other than row and column filters 
• does not materialize the resulting table when called directly in a filter argument of CALCULATE or CALCULATETABLE 
• via ALLSELECTED([<tableName> | <columnName>[, <columnName>[, <columnName>[,…]]
• {parameter|optional} tableName
• the name of an existing table 
• cannot be an expression
• {parameter|optional} columnName
• the name of an existing column using standard DAX syntax, usually fully qualified
• cannot be an expression 
• if there is one argument, the argument is either tableName or columnName [1]
• if there is more than one argument, they must be columns from the same table [1] 
• {scenario} used to obtain visual totals in queries [1] 
• {scenario} used as a table expression when it has at least one argument [2] 
• {scenario} used without arguments only as a CALCULATE or CALCULATETABLE modifier [2]  
• {distinction} different from ALL() because 
• it retains all filters explicitly set within the query [1] 
• it retains all context filters other than row and column filters [1] 
• {limitation}[DirectQuery mode] not supported when used in calculated columns or RLS rules [1] 
• only DAX function that leverages shadow filter contexts [3] 
• has a slightly different behavior when
• used in SUMMARIZECOLUMNS 
• mostly produces the expected result [3] 
• removes filters for the currently-iterated group-by column, restoring the original filter set by SUMMARIZECOLUMNS itself [3] 
• SUMMARIZECOLUMNS  can be used in nearly all the visuals [3] 
• inside an iterator
• {warning} can produce weird results [3] 
• does not return the values of a column (or table) filtered outside a visual [3] 
• displays different behaviors, depending on whether it is used in SUMMARIZECOLUMNS or not, and on the presence of shadow filter contexts [3]
• {best practice} don’t create a measure that uses ALLSELECTED within an iteration [3]
•  it can produce unexpected results, poor performance, and difficult-to-understand calculations.
• {best practice} minimize the use of measures that contain ALLSELECTED [3]
• can be safely used only in measures that are directly placed in the reports [3] 
•  

Previous Post <<||>> Next Post

References: 
[1] Microsoft Learn (2026) DAX: ALLSELECTED [link]
[2] DAX Guide (2026) ALLSELECTED DAX Function (Filter) SQL[link]
[3] SQLBI (2026) ALLSELECTED Best Practices [link]