Co-authored by

What Are Tableau LOD Expressions and Why Are They Hard to Translate?

Quick answer: LOD (Level of Detail) expressions let Tableau users control aggregation granularity independent of what dimensions appear in a visualisation. They are hard to translate because DAX has no direct syntactic equivalent — you need to compose CALCULATE, ALLEXCEPT, REMOVEFILTERS, and iterator functions to achieve the same results.

If you have spent any time migrating Tableau workbooks to Power BI, you already know that LOD expressions are the bottleneck. The visualisations translate easily enough — a bar chart is a bar chart. Data sources map to Power Query connections without drama. But the moment you open a calculated field and see { FIXED [Customer] : SUM([Sales]) }, the straightforward migration becomes a modelling exercise.

Tableau's LOD expression syntax is declarative: you state the grain you want, and Tableau figures out the query. DAX is imperative: you manipulate filter context step by step using CALCULATE and filter modifier functions. Both approaches reach the same result, but the mental model is different enough that direct translation requires understanding both paradigms.

This guide provides a systematic mapping between every LOD expression type and its DAX equivalent, with working code for each pattern. It assumes you understand basic Tableau calculated fields and are learning DAX — or that you are a DAX developer inheriting a Tableau migration and need to decode the source calculations. For the broader migration process, our Tableau to Power BI migration guide covers licensing, data sources, timelines, and project planning.

How Do LOD Expressions Work in Tableau?

Quick answer: LOD expressions use the syntax { FIXED | INCLUDE | EXCLUDE <dimensions> : <aggregate expression> } to compute aggregations at a specific granularity, regardless of the dimensions displayed in the current visualisation.

Before translating anything, you need to understand the three LOD types and how they relate to the visualisation's level of detail (the "viz LOD").

The Three LOD Types

Every LOD expression follows this structure:

{ [FIXED | INCLUDE | EXCLUDE] <dimension1> [, <dimension2>] : <aggregate(measure)> }

FIXED Example

{ FIXED [Region] : SUM([Sales]) }

This returns total sales per region. If the visualisation shows data at the city level, every city row displays its region's total. If the visualisation shows data at the country level, the same region totals appear. The viz dimensions do not matter — FIXED ignores them.

INCLUDE Example

{ INCLUDE [Customer Name] : SUM([Sales]) }

If the viz shows Region, this computes sales per Region + Customer Name. The result is finer-grained than the viz. Tableau then reaggregates (typically AVG or MAX) when displaying the result at the viz level.

EXCLUDE Example

{ EXCLUDE [Region] : SUM([Sales]) }

If the viz shows Region and Category, this computes sales per Category only — stripping Region from the grain. Every region row for the same category shows the same number.

Filter Interaction — A Critical Detail

FIXED expressions ignore dimension filters and measure filters — they only respect context filters, data source filters, and extract filters. INCLUDE and EXCLUDE expressions respect all filters, including dimension filters. This behavioural difference matters during translation because DAX filter context does not automatically distinguish between these filter types. You need to decide explicitly which filters to preserve and which to override.

How Do You Translate FIXED LOD Expressions to DAX?

Quick answer: Use CALCULATE with ALLEXCEPT to fix the aggregation at specific dimensions, or use a REMOVEFILTERS + variable pattern for complex multi-dimension scenarios.

FIXED is the most common LOD type and the one you will translate most often. The core idea: remove all filters except the dimensions you want to fix on.

Pattern 1: Single-Dimension FIXED

Tableau:

{ FIXED [Region] : SUM([Sales]) }

DAX measure:

Regional Sales =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    ALLEXCEPT( Sales, Sales[Region] )
)

ALLEXCEPT removes all context filters on the Sales table except the filter on Region. This means regardless of what slicers or visual dimensions are active, the measure returns the total for the current region — matching the FIXED behaviour.

Pattern 2: Multi-Dimension FIXED

Tableau:

{ FIXED [Customer ID], [Product Name] : MIN([Order Date]) }

DAX measure:

First Order by Customer Product =
CALCULATE(
    MIN( Sales[Order Date] ),
    ALLEXCEPT( Sales, Sales[Customer ID], Sales[Product Name] )
)

Each additional FIXED dimension becomes another column argument in ALLEXCEPT. The function preserves filters on all listed columns and removes everything else.

Pattern 3: FIXED with No Dimensions (Grand Total)

Tableau:

{ FIXED : SUM([Sales]) }

A FIXED expression with no dimensions computes a grand total across the entire dataset, ignoring all filters.

DAX measure:

Grand Total Sales =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    REMOVEFILTERS()
)

REMOVEFILTERS() with no arguments clears all filters from all tables — the DAX equivalent of "ignore everything."

Pattern 4: The Variable Approach for Complex FIXED

For nested or conditional FIXED expressions, the ALLEXCEPT approach can break down because ALLEXCEPT only works against a single base table. A more robust pattern uses variables to capture the dimension values, then applies them inside CALCULATE:

Tableau:

{ FIXED [Category] : AVG({ FIXED [Sub-Category] : SUM([Sales]) }) }

DAX measure:

Avg Subcategory Sales by Category =
VAR SubcategorySales =
    ADDCOLUMNS(
        SUMMARIZE( Sales, Sales[Category], Sales[Sub-Category] ),
        "@SubSales", CALCULATE( SUM( Sales[Sales Amount] ) )
    )
RETURN
AVERAGEX(
    FILTER( SubcategorySales, Sales[Category] = MAX( Sales[Category] ) ),
    [@SubSales]
)

This first builds a table of sales per sub-category (inner FIXED), groups by category, then averages. The variable pattern keeps the logic readable and avoids deeply nested CALCULATE calls.

How Do You Translate INCLUDE LOD Expressions to DAX?

Quick answer: Use AVERAGEX or SUMX iterating over VALUES of the included dimension, with CALCULATE for context transition — this adds granularity below the visual level, matching INCLUDE behaviour.

INCLUDE expressions are less common than FIXED but appear regularly in "average per customer" or "max per transaction" patterns where you need a finer grain than the viz provides.

Pattern 1: Average Sales per Customer (Viz Shows Region)

Tableau:

AVG({ INCLUDE [Customer Name] : SUM([Sales]) })

This computes sales per customer (finer grain), then averages those customer totals at whatever viz level is active.

DAX measure:

Avg Sales per Customer =
AVERAGEX(
    VALUES( Sales[Customer Name] ),
    CALCULATE( SUM( Sales[Sales Amount] ) )
)

VALUES( Sales[Customer Name] ) returns the distinct customers visible in the current filter context. CALCULATE triggers context transition, evaluating the SUM for each customer individually. AVERAGEX then averages those per-customer totals. The result matches the INCLUDE + AVG aggregation pattern.

Pattern 2: Max Transaction Amount per Product

Tableau:

{ INCLUDE [Transaction ID] : SUM([Amount]) }

Displayed with MAX aggregation.

DAX measure:

Max Transaction Amount =
MAXX(
    VALUES( Sales[Transaction ID] ),
    CALCULATE( SUM( Sales[Amount] ) )
)

The pattern is identical — swap the outer iterator to match whatever aggregation Tableau applies to the INCLUDE expression.

Pattern 3: INCLUDE with Multiple Dimensions

Tableau:

{ INCLUDE [Sales Rep], [Product Line] : MAX([Sales]) }

DAX measure:

Avg of Max Sales by Rep and Product =
AVERAGEX(
    SUMMARIZE( Sales, Sales[Sales Rep], Sales[Product Line] ),
    CALCULATE( MAX( Sales[Sales] ) )
)

When the INCLUDE adds multiple dimensions, use SUMMARIZE to generate the distinct dimension combinations instead of VALUES (which handles only a single column).

How Do You Translate EXCLUDE LOD Expressions to DAX?

Quick answer: Use CALCULATE with REMOVEFILTERS on the excluded dimension to strip it from the filter context, producing a coarser-grained aggregation — the DAX equivalent of Tableau's EXCLUDE.

EXCLUDE is used for "percent of total," "difference from average," and "benchmark comparison" calculations where you need to aggregate at a higher level than the viz.

Pattern 1: Total Sales Excluding Region (Viz Shows Region + Category)

Tableau:

{ EXCLUDE [Region] : SUM([Sales]) }

DAX measure:

Sales Excluding Region =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    REMOVEFILTERS( Sales[Region] )
)

REMOVEFILTERS clears the filter on Region, so the measure returns total sales for the current category (and any other active filters) across all regions.

Pattern 2: Percent of Total by Category

Tableau:

SUM([Sales]) / { EXCLUDE [Sub-Category] : SUM([Sales]) }

DAX measure:

Pct of Category Sales =
DIVIDE(
    SUM( Sales[Sales Amount] ),
    CALCULATE(
        SUM( Sales[Sales Amount] ),
        REMOVEFILTERS( Sales[Sub-Category] )
    )
)

The numerator respects all filters (current sub-category). The denominator removes the sub-category filter, returning the category total. The division produces the percentage contribution.

Pattern 3: Difference from Overall Average

Tableau:

SUM([Sales]) - { EXCLUDE [Region] : AVG([Sales]) }

DAX measure:

Sales vs Avg Excl Region =
SUM( Sales[Sales Amount] ) -
CALCULATE(
    AVERAGE( Sales[Sales Amount] ),
    REMOVEFILTERS( Sales[Region] )
)

Pattern 4: EXCLUDE Multiple Dimensions

Tableau:

{ EXCLUDE [Region], [Category] : SUM([Sales]) }

DAX measure:

Sales Excluding Region and Category =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    REMOVEFILTERS( Sales[Region] ),
    REMOVEFILTERS( Sales[Category] )
)

Each excluded dimension gets its own REMOVEFILTERS call inside CALCULATE. Multiple REMOVEFILTERS arguments combine with AND logic — both filters are cleared simultaneously.

What Does the Complete Translation Table Look Like?

Quick answer: The table below maps 15 common Tableau LOD patterns to their DAX equivalents — covering FIXED, INCLUDE, EXCLUDE, nested expressions, and conditional LODs.

The table uses T as a shorthand for the table name and [M] for the measure column. Replace with your actual table and column references.

What Are the Common Gotchas When Translating LOD to DAX?

Quick answer: The biggest traps are misunderstanding row context vs filter context, assuming ALLEXCEPT works across relationships, forgetting that FIXED ignores dimension filters but CALCULATE does not by default, and overlooking evaluation order differences between Tableau and DAX.

Gotcha 1: Row Context vs Filter Context

Tableau does not have this distinction. Every LOD expression operates at the query level — there is no concept of "iterating row by row." DAX has two evaluation contexts that behave differently:

• Filter context is the set of active filters (slicers, visual dimensions, CALCULATE modifications) that restrict which rows are visible to an aggregation
• Row context is created by iterators (SUMX, AVERAGEX, FILTER) and calculated columns — it processes one row at a time but does not filter the model

When you write CALCULATE( SUM(Sales[Amount]) ) inside an iterator, context transition converts the current row context into a filter context. This is how INCLUDE-style patterns work. If you forget that context transition happens implicitly when you reference a measure inside an iterator, you get unexpected results.

The practical rule: if your Tableau expression uses INCLUDE, you almost certainly need an iterator in DAX, and context transition is doing the heavy lifting inside that iterator.

Gotcha 2: ALLEXCEPT Only Works on a Single Table

ALLEXCEPT( Sales, Sales[Region] ) works because both arguments reference the same table. You cannot write ALLEXCEPT( Sales, Geography[Region] ) — it will throw an error. If the dimension you want to fix on lives in a related dimension table (as it should in a proper star schema), you need to reference the relationship:

Regional Sales =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    REMOVEFILTERS( Sales ),
    VALUES( Geography[Region] )
)

This clears all filters on the fact table, then applies back only the current region from the dimension table. It achieves the same result as ALLEXCEPT but works across relationships.

Gotcha 3: FIXED Ignores Dimension Filters; CALCULATE Does Not

In Tableau, { FIXED [Region] : SUM([Sales]) } ignores dimension filters on the worksheet. If a user applies a dimension filter to show only "Bikes," the FIXED expression still returns total sales for all products within each region.

In DAX, CALCULATE( SUM(Sales[Amount]), ALLEXCEPT(Sales, Sales[Region]) ) removes filters on the Sales table but does not remove filters coming from other tables through relationships. A slicer on Product[Category] = "Bikes" propagates through the relationship and still filters the Sales table.

To match FIXED's filter-ignoring behaviour exactly, you may need REMOVEFILTERS on the related dimension tables too:

Regional Sales All Products =
CALCULATE(
    SUM( Sales[Sales Amount] ),
    REMOVEFILTERS( 'Product' ),
    ALLEXCEPT( Sales, Sales[Region] )
)

Gotcha 4: Evaluation Order Differences

Tableau's order of operations for LOD expressions is: extract filters first, then data source filters, then context filters, then FIXED LOD, then dimension filters, then INCLUDE/EXCLUDE LOD, then measure filters. This means FIXED LOD results are computed before dimension filters are applied.

DAX has no equivalent pipeline. All filter context — from slicers, visual dimensions, RLS rules, and CALCULATE arguments — is resolved at the point of evaluation. There is no "before dimension filters" stage. When translating a FIXED expression that relied on ignoring dimension filters, you need to explicitly strip those filters using REMOVEFILTERS or ALL on the relevant columns.

Gotcha 5: Nested LODs Require Variables in DAX

Tableau allows nesting LOD expressions freely:

{ FIXED [Category] : AVG({ FIXED [Sub-Category] : SUM([Sales]) }) }

DAX does not let you nest CALCULATE calls in the same way. The inner expression needs to be materialised first — typically as a variable holding a SUMMARIZE or ADDCOLUMNS table — and the outer expression iterates over that variable. The pattern shown in the FIXED section above (Pattern 4) is the standard approach.

When Is There No Direct DAX Equivalent?

Quick answer: Tableau's INCLUDE and EXCLUDE expressions that depend on the viz LOD have no static DAX equivalent because DAX measures do not know which dimensions a visual is displaying — you must design the measure for a specific analytical scenario rather than relying on dynamic grain adjustment.

This is the fundamental architectural difference. In Tableau, an INCLUDE or EXCLUDE expression adjusts dynamically based on what dimensions are on the shelf. Drop a new dimension onto the view and the LOD expression recalculates at a different grain. In DAX, a measure's behaviour is determined by the filter context, which comes from slicers and the visual's grouping — but the measure itself does not "know" which columns the visual is grouping by.

The Workaround: Design for the Scenario

Rather than trying to build a generic "INCLUDE any dimension" measure, identify the specific analytical question:

• "Average sales per customer, regardless of how the report groups data" — build the measure with AVERAGEX( VALUES(Customer[CustomerID]), ... )
• "Total excluding the sub-category breakdown" — build the measure with REMOVEFILTERS( Product[Sub-Category] )

Each scenario gets its own measure. This feels more verbose than a single Tableau LOD expression, but it produces measures that are explicit, testable, and performant. In practice, most Tableau workbooks use a handful of LOD patterns repeatedly. Translating those patterns into named DAX measures creates a cleaner, more maintainable model.

Table Calculations vs LOD Expressions

Some Tableau LOD use cases — especially running totals, moving averages, and rank-based filters — are actually better served by DAX time intelligence functions or window functions rather than CALCULATE + filter modifiers. For instance, Tableau's WINDOW_AVG(SUM([Sales]), -2, 0) for a three-month moving average maps to:

Moving Avg 3 Month =
AVERAGEX(
    DATESINPERIOD( 'Date'[Date], MAX( 'Date'[Date] ), -3, MONTH ),
    [Total Sales]
)

If a Tableau calculation uses both LOD expressions and table calculations together, split them into separate DAX measures. LOD logic goes into CALCULATE-based measures; table-calculation logic goes into iterator or time-intelligence measures.

How Does Performance Compare Between LOD Expressions and DAX CALCULATE?

Quick answer: DAX CALCULATE operating against Power BI's in-memory VertiPaq engine is typically faster than Tableau LOD expressions running as nested SQL sub-selects against a relational database — but poorly written DAX iterators can be significantly slower than equivalent FIXED expressions.

How Tableau LOD Queries Execute

Tableau translates LOD expressions into nested SELECT sub-queries sent to the underlying database. A { FIXED [Region] : SUM([Sales]) } becomes a sub-query grouped by Region, joined back to the main query. Performance depends on the database engine — fast databases (Snowflake, BigQuery) handle this efficiently; slower ones (MySQL, legacy Oracle instances) can struggle with complex nested LODs.

When using Tableau Data Extracts (.hyper files), LOD expressions run against Tableau's own columnar engine, which is well-optimised for this workload.

How DAX CALCULATE Executes

Power BI's VertiPaq engine stores data in a compressed, in-memory columnar format. CALCULATE with simple column filters (Boolean predicates) and functions like ALLEXCEPT translate directly into Storage Engine queries — fast, parallelised, and cache-friendly. This is where DAX typically outperforms LOD expressions against relational databases.

The performance risk in DAX comes from iterators. AVERAGEX( VALUES(Customer[Name]), CALCULATE(SUM(Sales[Amount])) ) triggers context transition for every distinct customer. If you have 500,000 customers, that is 500,000 CALCULATE evaluations. This scenario — common in INCLUDE translations — can be slow.

Performance Guidelines

The general principle: avoid iterating over fact tables. Iterate over dimension tables. If your INCLUDE translation requires iterating over a fact-table column with millions of distinct values, restructure the calculation so the iteration happens over a dimension table with thousands of values and let relationships propagate the filter.

For more DAX performance patterns, see our DAX best practices guide.

What Does a Real-World Migration Example Look Like?

Quick answer: A Tableau customer cohort analysis using nested FIXED LODs translates to a DAX pattern with CALCULATE, ALLEXCEPT, and AVERAGEX — here is the full worked example.

Consider a Tableau workbook that classifies customers by their first purchase month and calculates average lifetime spend per cohort. This is a common analytics pattern in retail and SaaS.

Tableau Calculated Fields

First Purchase Month (per customer):

{ FIXED [Customer ID] : MIN([Order Date]) }

Customer Lifetime Sales:

{ FIXED [Customer ID] : SUM([Sales]) }

Average Lifetime Sales by Cohort:

AVG({ INCLUDE [Customer ID] : SUM([Sales]) })

The viz groups by the first purchase month, showing the average lifetime spend of customers who first purchased in each month.

DAX Translation

Step 1: First Purchase Date (calculated column on Customer table):

First Purchase Date =
CALCULATE(
    MIN( Sales[Order Date] ),
    ALLEXCEPT( Sales, Sales[Customer ID] )
)

Or, if Customer is a dimension table with a relationship to Sales:

First Purchase Date =
CALCULATE( MIN( Sales[Order Date] ) )

In a calculated column on the Customer table, context transition automatically filters Sales to the current customer — no ALLEXCEPT needed.

Step 2: Average Lifetime Sales per Cohort (measure):

Avg Lifetime Sales =
AVERAGEX(
    VALUES( Customer[Customer ID] ),
    CALCULATE( SUM( Sales[Sales Amount] ) )
)

When this measure is placed in a visual grouped by Customer[First Purchase Date] (truncated to month), it returns the average of each customer's total sales within the cohort. The visual's filter context restricts VALUES( Customer[Customer ID] ) to customers in that cohort, and context transition inside CALCULATE computes each customer's total.

Key Observations

• The Tableau version uses three separate calculated fields. The DAX version uses one calculated column and one measure. DAX tends to consolidate logic into fewer, more reusable components.
• The Tableau FIXED LOD for "Customer Lifetime Sales" has no direct measure equivalent because a measure cannot return a per-customer value without an iterator. The AVERAGEX pattern handles both the per-customer calculation and the aggregation in a single expression.
• In a properly modelled star schema, the calculated column on the Customer table replaces the first FIXED LOD entirely — the relationship handles the grain. This is why data modelling is the single most impactful step in a migration.

How Should You Approach the Translation Process?

Quick answer: Catalogue every LOD expression in your Tableau workbooks, classify each by type (FIXED/INCLUDE/EXCLUDE), apply the matching DAX pattern from this guide, and validate results row by row against the original Tableau output.

Step 1: Export the Calculation Inventory

Open each Tableau workbook (.twb or .twbx) and list every calculated field that contains { FIXED, { INCLUDE, or { EXCLUDE. Note the dimensions, the aggregate function, and where the calculated field is used (which worksheets, what aggregation is applied on the shelf).

Step 2: Classify and Prioritise

Sort the list by frequency of use. A FIXED expression used in 20 dashboards is higher priority than one used in a single ad-hoc worksheet. Group similar patterns — you will likely find that 5-6 DAX measure templates cover 80% of your LOD expressions.

Step 3: Translate Using the Pattern Table

Match each LOD expression to a row in the translation table above. Write the DAX measure, name it clearly (include what it calculates and at what grain), and document the original Tableau expression in a comment or in a separate translation log.

Step 4: Validate

Run the Tableau workbook and the Power BI report side by side with identical data. Compare specific numbers at specific filter combinations. Pay particular attention to edge cases: null values, empty dimension members, and filter interactions between slicers and the LOD-derived measures.

For a complete migration workflow including data source mapping, report rebuilding, and user training, see our Tableau migration service page.

Frequently Asked Questions

Q: What is the DAX equivalent of a Tableau FIXED LOD expression?

Use CALCULATE with ALLEXCEPT to fix the aggregation at specific dimensions. For example, { FIXED [Region] : SUM([Sales]) } in Tableau becomes CALCULATE( SUM(Sales[Sales Amount]), ALLEXCEPT(Sales, Sales[Region]) ) in DAX. The ALLEXCEPT function removes all context filters on the table except the columns you specify, effectively fixing the calculation grain. For a grand total with no fixed dimensions, use CALCULATE( SUM(Sales[Sales Amount]), REMOVEFILTERS() ).

Q: How do I convert Tableau INCLUDE LOD expressions to DAX?

INCLUDE LOD expressions map to iterator functions in DAX. Use AVERAGEX, SUMX, or MAXX iterating over VALUES of the included dimension, with CALCULATE triggering context transition inside the iterator. For example, AVG({ INCLUDE [Customer] : SUM([Sales]) }) becomes AVERAGEX( VALUES(Customer[Customer ID]), CALCULATE(SUM(Sales[Sales Amount])) ). The iterator adds the per-customer grain, and the outer aggregation (AVERAGEX) matches whatever aggregation Tableau applies to the INCLUDE result.

Q: Can I automate the translation of Tableau LOD expressions to DAX?

Partially. Tools like BIChart and Microsoft's Fabric migration utilities can handle simple FIXED patterns automatically. However, nested LODs, conditional LODs, and expressions that depend on specific filter interactions require manual translation and validation. For enterprise migrations with hundreds of calculated fields, the recommended approach is to automate the catalogue extraction, use templates for the common patterns, and reserve senior analyst time for the complex cases.

Q: Why does my DAX measure return different results than the Tableau LOD expression?

The most common cause is filter context differences. Tableau FIXED expressions ignore dimension filters by default, while DAX CALCULATE respects all active filters unless you explicitly remove them with REMOVEFILTERS or ALL. Check whether slicer selections or visual filters are propagating into your DAX measure when they should not be. Use DAX Query View in Power BI Desktop to test the measure with explicit filter combinations and isolate the discrepancy. Our CALCULATE deep dive covers filter context mechanics in detail.

Q: Is DAX harder to learn than Tableau LOD expressions?

DAX has a steeper initial learning curve because you need to understand filter context, row context, and context transition — concepts that do not exist in Tableau's more declarative model. However, once you internalise these concepts (typically 4-6 weeks of hands-on practice for an experienced Tableau analyst), DAX becomes more predictable and powerful. LOD expressions can produce surprising results when filter interactions are complex; DAX forces you to be explicit about every filter, which makes debugging easier. Start with our DAX functions reference for a structured learning path.

Q: How do nested Tableau LOD expressions translate to DAX?

Nested LODs — an LOD expression inside another LOD expression — require a multi-step approach in DAX. Materialise the inner expression as a variable using ADDCOLUMNS and SUMMARIZE, then iterate over that variable with the outer aggregation. For example, { FIXED [Category] : AVG({ FIXED [Sub-Category] : SUM([Sales]) }) } becomes a variable that builds a sub-category sales table, followed by an AVERAGEX filtered to the current category. There is no single-line DAX equivalent; the variable pattern is the standard approach.

Q: What about Tableau table calculations — do they use the same DAX patterns?

No. Table calculations (RUNNING_TOTAL, WINDOW_AVG, RANK, LOOKUP) operate on the result set after aggregation, while LOD expressions operate during query execution. In DAX, table calculation equivalents typically use time intelligence functions (DATESINPERIOD, SAMEPERIODLASTYEAR), window functions (OFFSET, WINDOW — available since 2023), or ranking functions (RANKX). These are separate from the CALCULATE-based patterns used for LOD translation.