DAX and data models

Row Context vs Filter Context in Power BI, With DAX Examples

Row context evaluates a formula one row at a time, filter context against a filtered set of rows. How CALCULATE turns one into the other, with DAX examples.

Sajagan Thirugnanam

·

Updated

Row context is Power BI evaluating a formula one row at a time, as in a calculated column. Filter context is Power BI evaluating a formula against whatever subset of rows is filtered, as in a measure. CALCULATE converts row context into filter context, which is why wrapping SUM in CALCULATE fixes a measure that otherwise returns the same total for every row. This guide covers both, why they get confused, and how to debug a formula that isn't returning what you expect.

What context means in Power BI

Context is the set of rules that determines which rows of data a DAX formula sees when it runs. Power BI evaluates the same formula differently depending on where it is used: a calculated column, a measure, or a visual. The two types of context that matter most are row context and filter context.

Row context

Row context means Power BI evaluates an expression for one row at a time, and knows the values in that row's columns directly. It shows up in:

  • Calculated columns

  • Iterator functions, such as SUMX, AVERAGEX, and FILTER

Given a Sales table:

Product

Quantity

Unit Price

A

2

50

B

3

30

This calculated column:

Total Sales = Sales[Quantity] * Sales[Unit Price]

runs once per row: row 1 returns 2 × 50 = 100, row 2 returns 3 × 30 = 90. That row-by-row evaluation is row context.

Iterator functions create the same row context inside a measure:

Total Sales = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])

SUMX loops through the Sales table row by row, evaluates Sales[Quantity] * Sales[Unit Price] for each one, and sums the results.

Filter context

Filter context means Power BI evaluates a formula against whatever subset of rows is filtered. Filters can come from slicers, page filters, report filters, visual filters, relationships between tables, or a row and column selection in a matrix. Filter context governs measures and visual-level calculations.

Total Revenue = SUM(Sales[Revenue])

Put this measure in a visual broken down by Product, and Power BI applies a separate filter context for each product: one evaluation filtered to Product A, another filtered to Product B. The same measure returns a different number for each, because the filter context around it changed, not the formula.

Row context versus filter context at a glance


Row context

Filter context

Works on

The current row

A subset of data based on filters

Used in

Calculated columns, iterators

Measures, visuals

Behavior

Evaluates row by row

Evaluates the filtered data

Example

Sales[Qty] * Sales[Price]

SUM(Sales[Revenue])

Why row context does not filter the table

Row context knows the current row, but it does not automatically turn into a filter on the rest of the model. That gap is what breaks a calculated column like this:

Total Revenue Column = SUM(Sales[Revenue])

A reasonable guess is that this sums revenue per product, but every row returns the same grand total instead. SUM does not respect row context on its own. Without a filter, it sums the whole table, once per row, regardless of which row is current.

Context transition: how CALCULATE fixes it

CALCULATE converts row context into filter context. This is called context transition, and it is why CALCULATE shows up in almost every non-trivial DAX formula.

Total Revenue Column = CALCULATE(SUM(Sales[Revenue]))

Wrapping SUM in CALCULATE turns the current row context into a filter context scoped to that row, then evaluates SUM inside it. The result: each row now returns revenue for that row's own values, not the grand total.

The same pattern applies to a calculated column in a Customers table that needs each customer's total sales:

Customer Total Sales = CALCULATE(SUM(Sales[Revenue]))

Without CALCULATE, this returns the same grand total on every customer row. With it, context transition scopes SUM to each customer.

A simple rule of thumb: a calculated column defaults to row context, a measure defaults to filter context, and CALCULATE is the bridge between them. One exception to remember: an iterator function like SUMX creates row context even inside a measure.

Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])

Here SUMX creates row context internally, evaluates the expression per row, and sums the results, all inside a measure that otherwise runs in filter context.

What builds filter context in a real report

A measure's result depends on the combination of the visual it sits in, any slicers and filters on the page, the relationships between tables, and any CALCULATE or FILTER inside the formula itself. When a measure returns something unexpected, three questions usually find the cause:

  1. What is the visual filtering on?

  2. What relationships are applying a filter you did not write explicitly?

  3. Does the formula create row context using an iterator like SUMX?

Filter context depends on the model's relationships. A missing or incorrect relationship, or a fact table row whose key does not exist in the related dimension table, both produce unexpected totals, because the affected rows do not get filtered the way you expect. DIVIDE handles the blank results filtering can produce:

Profit Margin = DIVIDE([Profit], [Revenue], 0)

The third argument is the value to return instead of an error when the denominator is blank or zero.

Two related terms: query context and nested row context

Two more terms come up in advanced DAX, and both are extensions of the two core concepts above, not separate ideas:

  • Query context is the filter context a visual builds for each cell it renders. In a matrix broken down by Product and Year, Power BI evaluates the measure separately per cell, and query context is what generates the filter context behind each evaluation.

  • Nested row context happens when one iterator is used inside another, such as SUMX inside SUMX, which creates more than one "current row" at once. Modern DAX generally handles this with VAR rather than the older EARLIER() function. Our DAX variables guide covers VAR in depth.

Common mistakes

  • Treating a measure like a calculated column. Measures do not store a value per row; they calculate dynamically against whatever filter context surrounds them.

  • Expecting SUM to respect row context automatically. It does not; wrap it in CALCULATE if you need it to.

  • Adding CALCULATE without knowing what filter it changes. Before adding it, ask what filter context you are creating or overriding.

For the filter modifiers that change filter context on purpose, such as ALL and ALLSELECTED, see our ALLSELECTED vs ALL guide. For DAX from the ground up, see our complete DAX guide.

FAQs

What is row context in Power BI?

Row context is Power BI evaluating an expression for one row at a time. It is the default context in calculated columns, and iterator functions like SUMX create it inside measures too.

What is filter context in Power BI?

Filter context is the set of filters applied to the data when a DAX formula is evaluated. It comes from slicers, visuals, report and page filters, and table relationships.

What is the main difference between row context and filter context?

Row context evaluates data one row at a time. Filter context evaluates a formula against a filtered subset of the data. CALCULATE converts the first into the second.

Do measures use row context?

Measures default to filter context, but an iterator function inside a measure, such as SUMX, FILTER, or AVERAGEX, creates row context internally while the measure as a whole still runs inside filter context.

Sources

Row context is Power BI evaluating a formula one row at a time, as in a calculated column. Filter context is Power BI evaluating a formula against whatever subset of rows is filtered, as in a measure. CALCULATE converts row context into filter context, which is why wrapping SUM in CALCULATE fixes a measure that otherwise returns the same total for every row. This guide covers both, why they get confused, and how to debug a formula that isn't returning what you expect.

What context means in Power BI

Context is the set of rules that determines which rows of data a DAX formula sees when it runs. Power BI evaluates the same formula differently depending on where it is used: a calculated column, a measure, or a visual. The two types of context that matter most are row context and filter context.

Row context

Row context means Power BI evaluates an expression for one row at a time, and knows the values in that row's columns directly. It shows up in:

  • Calculated columns

  • Iterator functions, such as SUMX, AVERAGEX, and FILTER

Given a Sales table:

Product

Quantity

Unit Price

A

2

50

B

3

30

This calculated column:

Total Sales = Sales[Quantity] * Sales[Unit Price]

runs once per row: row 1 returns 2 × 50 = 100, row 2 returns 3 × 30 = 90. That row-by-row evaluation is row context.

Iterator functions create the same row context inside a measure:

Total Sales = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])

SUMX loops through the Sales table row by row, evaluates Sales[Quantity] * Sales[Unit Price] for each one, and sums the results.

Filter context

Filter context means Power BI evaluates a formula against whatever subset of rows is filtered. Filters can come from slicers, page filters, report filters, visual filters, relationships between tables, or a row and column selection in a matrix. Filter context governs measures and visual-level calculations.

Total Revenue = SUM(Sales[Revenue])

Put this measure in a visual broken down by Product, and Power BI applies a separate filter context for each product: one evaluation filtered to Product A, another filtered to Product B. The same measure returns a different number for each, because the filter context around it changed, not the formula.

Row context versus filter context at a glance


Row context

Filter context

Works on

The current row

A subset of data based on filters

Used in

Calculated columns, iterators

Measures, visuals

Behavior

Evaluates row by row

Evaluates the filtered data

Example

Sales[Qty] * Sales[Price]

SUM(Sales[Revenue])

Why row context does not filter the table

Row context knows the current row, but it does not automatically turn into a filter on the rest of the model. That gap is what breaks a calculated column like this:

Total Revenue Column = SUM(Sales[Revenue])

A reasonable guess is that this sums revenue per product, but every row returns the same grand total instead. SUM does not respect row context on its own. Without a filter, it sums the whole table, once per row, regardless of which row is current.

Context transition: how CALCULATE fixes it

CALCULATE converts row context into filter context. This is called context transition, and it is why CALCULATE shows up in almost every non-trivial DAX formula.

Total Revenue Column = CALCULATE(SUM(Sales[Revenue]))

Wrapping SUM in CALCULATE turns the current row context into a filter context scoped to that row, then evaluates SUM inside it. The result: each row now returns revenue for that row's own values, not the grand total.

The same pattern applies to a calculated column in a Customers table that needs each customer's total sales:

Customer Total Sales = CALCULATE(SUM(Sales[Revenue]))

Without CALCULATE, this returns the same grand total on every customer row. With it, context transition scopes SUM to each customer.

A simple rule of thumb: a calculated column defaults to row context, a measure defaults to filter context, and CALCULATE is the bridge between them. One exception to remember: an iterator function like SUMX creates row context even inside a measure.

Total Revenue = SUMX(Sales, Sales[Quantity] * Sales[Unit Price])

Here SUMX creates row context internally, evaluates the expression per row, and sums the results, all inside a measure that otherwise runs in filter context.

What builds filter context in a real report

A measure's result depends on the combination of the visual it sits in, any slicers and filters on the page, the relationships between tables, and any CALCULATE or FILTER inside the formula itself. When a measure returns something unexpected, three questions usually find the cause:

  1. What is the visual filtering on?

  2. What relationships are applying a filter you did not write explicitly?

  3. Does the formula create row context using an iterator like SUMX?

Filter context depends on the model's relationships. A missing or incorrect relationship, or a fact table row whose key does not exist in the related dimension table, both produce unexpected totals, because the affected rows do not get filtered the way you expect. DIVIDE handles the blank results filtering can produce:

Profit Margin = DIVIDE([Profit], [Revenue], 0)

The third argument is the value to return instead of an error when the denominator is blank or zero.

Two related terms: query context and nested row context

Two more terms come up in advanced DAX, and both are extensions of the two core concepts above, not separate ideas:

  • Query context is the filter context a visual builds for each cell it renders. In a matrix broken down by Product and Year, Power BI evaluates the measure separately per cell, and query context is what generates the filter context behind each evaluation.

  • Nested row context happens when one iterator is used inside another, such as SUMX inside SUMX, which creates more than one "current row" at once. Modern DAX generally handles this with VAR rather than the older EARLIER() function. Our DAX variables guide covers VAR in depth.

Common mistakes

  • Treating a measure like a calculated column. Measures do not store a value per row; they calculate dynamically against whatever filter context surrounds them.

  • Expecting SUM to respect row context automatically. It does not; wrap it in CALCULATE if you need it to.

  • Adding CALCULATE without knowing what filter it changes. Before adding it, ask what filter context you are creating or overriding.

For the filter modifiers that change filter context on purpose, such as ALL and ALLSELECTED, see our ALLSELECTED vs ALL guide. For DAX from the ground up, see our complete DAX guide.

FAQs

What is row context in Power BI?

Row context is Power BI evaluating an expression for one row at a time. It is the default context in calculated columns, and iterator functions like SUMX create it inside measures too.

What is filter context in Power BI?

Filter context is the set of filters applied to the data when a DAX formula is evaluated. It comes from slicers, visuals, report and page filters, and table relationships.

What is the main difference between row context and filter context?

Row context evaluates data one row at a time. Filter context evaluates a formula against a filtered subset of the data. CALCULATE converts the first into the second.

Do measures use row context?

Measures default to filter context, but an iterator function inside a measure, such as SUMX, FILTER, or AVERAGEX, creates row context internally while the measure as a whole still runs inside filter context.

Sources

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English