This chapter reframes DAX as an interactive language whose results are constantly shaped by evaluation context. In Power BI reports, slicers, visuals, and filters silently inject context—often via an implicit CALCULATE—so a measure is reevaluated for every combination of user-driven filters. The chapter contrasts Interactive DAX (on the report canvas) with Standard DAX (standalone queries for learning, debugging, and validation), and stresses that predictable outcomes come from understanding how DAX functions, the semantic model, and user actions jointly define which rows are visible and how filters propagate.
At the core is the semantic model, which unifies tables through relationships so filters flow automatically and queries can traverse related data without explicit joins. DAX “sees” expanded tables, allowing measures to reference columns across relationship paths, while data lineage preserves each column’s origin to ensure correct filter behavior. The chapter explains why expressions can work across indirect paths and warns that certain transformations (for example, SELECTCOLUMNS or some virtual tables) can break lineage, leading to unexpected results; maintaining lineage is therefore essential for reliable, context-aware calculations.
Moving beyond simple models, the chapter covers real-world scenarios with multiple fact tables, shared dimensions, and purposely disconnected entities used for parameters, what-if analysis, and controlled interactivity. Authors must decide when to preserve, override, or selectively allow filters using interaction management techniques and functions such as TREATAS to reconnect virtual tables and steer filter flow. The outcome is a model-aware, filter-driven approach to DAX: designing measures that behave intentionally under changing user interactions and complex relationships, so numbers make sense at every slice, drill, and subtotal.
A Power BI report with matrix visual and slicer and filter panes.
Visual flow, from user interaction to execution of DAX in a specific context.
Physical model relationships and various components of a semantic model.
Relationship setup and navigating an expanded table
An illustration of a semantic model in interactive mode showing both connected (fact, dimension) entities and disconnected entities.
Summary
Every DAX calculation is context-driven—shaped by a combination of user interactions and semantic model relationships.
The semantic model enables automatic filter propagation across related tables, eliminating the need for explicit joins.
Expanded tables allow DAX to seamlessly access related dimension data without manual navigation.
Preserving data lineage is critical to ensuring filters propagate correctly through virtual tables and intermediate logic.
Disconnected tables are intentional design tools—used for scenarios like what-if analysis—and can be selectively reconnected using functions like TREATAS().
FAQ
What is Interactive DAX, and how is it different from Standard DAX?Interactive DAX runs inside a Power BI report. Slicers, visuals, and filters continuously shape the evaluation context, so measures reevaluate with every user action. Standard DAX runs as standalone queries (for example, in DAX Studio or Power BI Query View) in a fixed, controlled context—great for learning, debugging, and validating results without user-driven interference. Mastering both modes helps diagnose unexpected results and build robust solutions.What does “evaluation context” mean in DAX?Evaluation context is the set of conditions that determine what data is visible when a DAX expression runs. It’s shaped by three factors:
- DAX functions that add, modify, or remove filters (for example, CALCULATE, REMOVEFILTERS)
- The semantic model’s structure (relationships, filter propagation, expanded tables, and data lineage)
- User interactions (slicers, visuals, report/page filters, cross-filtering)
It ultimately defines which rows are included, which dimensions are visible, and how filters propagate through the model.How do user actions affect a measure on a report visual?User actions inject filters into the evaluation context. For example, a year slicer, a “Bikes” category filter, and a matrix row for a specific region together define the filters under which a measure (such as Total Sales) is evaluated. Each cell of a visual has its own context, so the measure is recalculated for each combination of slicer selections, filter panes, and visual intersections.Does Power BI automatically wrap my measures in CALCULATE?Yes. Behind the scenes, Power BI effectively evaluates measures as if they were wrapped in CALCULATE, merging all active filters from the canvas into a single filter context before running the expression. This is why a simple SUM behaves dynamically—it’s reevaluated under the accumulated filters created by slicers, filter panes, and each visual’s row/column context.How do relationships in the semantic model influence DAX?Relationships unify tables so that:
- Joins become implicit: once defined in Model View, DAX can reference related columns without explicit JOINs.
- Filters propagate automatically along relationship directions, recalculating dependent measures in real time.
This turns separate tables into a single, context-aware structure that DAX navigates during evaluation.What are “expanded tables,” and why do they matter?Expanded tables are a logical view DAX creates by extending a base table with columns from related one-side tables (and upstream through many-to-one chains). Benefits include:
- No explicit joins needed
- Direct access to deeply related attributes
- Cleaner, context-aware expressions
For example, CALCULATE(SUM(Sales[SalesAmount]), Category[CategoryName] = "Bikes") works because DAX traverses relationships to resolve the filter.What is data lineage in the semantic model?Data lineage is metadata that tracks a column’s origin and relationships. It lets DAX:
- Identify where a column comes from
- Understand how it connects to other tables through relationships
- Resolve filter paths across indirect relationships
Thanks to lineage, filters on a dimension like Product Category can correctly affect a fact table such as Sales, even when the connection is indirect.What breaks lineage, and what symptoms should I watch for?Lineage can be lost when you reshape data in ways that strip source references, such as:
- SELECTCOLUMNS with renamed (aliased) outputs
- Virtual tables built with functions like ADDCOLUMNS or SUMMARIZE that don’t preserve original metadata
- Transformations that decouple results from their semantic origins
Symptoms include unexpected filter behavior, incorrect totals, or blanks because the intermediate result is no longer connected to the model.What are disconnected tables, and when should I use them?Disconnected tables are intentionally not related to the model via relationships. They’re useful for:
- What-if parameter tables
- Slicers that drive measures without altering the underlying filter context
- Custom logic where relationships would add ambiguity or circular dependencies
You can capture inputs via SELECTEDVALUE and simulate filtering with functions like TREATAS or LOOKUPVALUE inside measures.How do I reconnect a disconnected or lineage-lost virtual table to enable filtering?Use TREATAS to map values from a disconnected table (or an intermediate recordset that lost lineage) to a model column, restoring filter propagation. Best practices:
- Prefer transformations that preserve lineage when possible
- Validate whether intermediate tables remain connected
- In complex or many-to-many scenarios, use TREATAS (and related techniques) to explicitly control filter flow
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
DAX Reimagined ebook for free
