Skip to content

Compare Tableau LOD grain with Power BI DAX.

Compare grouping and filter context before translating an LOD to DAX. This local sample computes the Tableau LOD side; it is not a native Power BI parity test.

Updated

Read locally in this browser.

↳sample.csvSynthetic sample

What profit ratio does each region’s fixed grain produce?

Synthetic East profit is 90 on sales of 300. West profit is 110 on sales of 400. This example computes the LOD ratios only, not a DAX equivalence claim.

“Explain the regional grain before translating this ratio to DAX.”

Worked example · authored synthetic data

  1. Read the original fileUse the existing browser reader
  2. Check the definitionKeep the grouping and filter scope explicit
  3. Compute the resultUse the existing xmetric engine
  4. Review the evidenceRead the exact cells and query

Calculation or query in this example

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

Exact sample file · Definitions and expected values

xmetricRegional profit ratio

Opening the labelled sample…

Expected values from the labelled sample; the browser recomputes them.

GroupResult
East0.3
West0.275
Use your own file

Drop one file anywhere on this page. It is read in your browser; no file is uploaded.

Nothing is uploaded.

Read locallyThe original file stays in the browser.

Share deliberatelyMCP shares supported metadata and requested results with the chat host.

Separate actionsOnline saves and support uploads require their own actions.

How does this workflow work?

What is the direct answer to this workbook question?

Tableau Level of Detail expressions and Power BI DAX both override the chart's filter context, but use different syntax. Tableau FIXED maps to DAX CALCULATE with ALLEXCEPT, EXCLUDE maps to CALCULATE with REMOVEFILTERS or ALL on the excluded dimension, and INCLUDE maps to SUMX over VALUES. Test the LOD side in the xmetric formula playground.

Why can translating an LOD to DAX change the result?

In Tableau (and xmetric), a Level of Detail expression explicitly states the grouping grain inside curly braces: { FIXED [Region] : SUM([Sales]) }.

In Microsoft Power BI DAX, you do not declare the target grain directly in a single keyword. Instead, you wrap a measure in CALCULATE() and pass filter-modifier functions (ALLEXCEPT, REMOVEFILTERS, ALL, VALUES) to add or strip filters from the current visual context.

How do the example LOD, DAX and SQL definitions differ?

The examples change grouping and filter context in different ways. Check those contexts before treating the written definitions as equivalent.

Analytical GoalTableau / xmetric LODPower BI DAX EquivalentStandard SQL Equivalent
Total across entire dataset (ignoring all chart dimensions){ FIXED : SUM([Sales]) }CALCULATE(SUM(Orders[Sales]), ALL(Orders))SUM(SUM(sales)) OVER ()
Fix aggregation at one specific dimension (Region){ FIXED [Region] : SUM([Sales]) }CALCULATE(SUM(Orders[Sales]), ALLEXCEPT(Orders, Orders[Region]))SUM(SUM(sales)) OVER (PARTITION BY region)
First purchase date per customer (used as a dimension){ FIXED [Customer ID] : MIN([Order Date]) }Calculated Column:<br>CALCULATE(MIN(Orders[Order Date]), ALLEXCEPT(Orders, Orders[Customer ID]))MIN(order_date) OVER (PARTITION BY customer_id)
Exclude one chart dimension (Category) for % of subtotal{ EXCLUDE [Category] : SUM([Sales]) }CALCULATE(SUM(Orders[Sales]), REMOVEFILTERS(Orders[Category]))SUM(SUM(sales)) OVER (PARTITION BY region)
Include a finer dimension (Order ID) then averageAVG({ INCLUDE [Order ID] : SUM([Sales]) })AVERAGEX(VALUES(Orders[Order ID]), CALCULATE(SUM(Orders[Sales])))AVG(order_sum) from a subquery grouped by order_id

How do ALLEXCEPT and FIXED differ in filter context?

Translating { FIXED [Region] : SUM([Sales]) } to CALCULATE(SUM(Orders[Sales]), ALLEXCEPT(Orders, Orders[Region])) works on a single flat table, but behaves differently from Tableau in two ways:

  1. Slicers on other columns: In Tableau, a regular Dimension Filter on Year is ignored by { FIXED [Region] : SUM([Sales]) } unless you promote Year to a Context Filter. In DAX, ALLEXCEPT(Orders, Orders[Region]) strips filters from all other columns on the Orders table, including report slicers on Orders[Year], unless your data model uses separate star-schema dimension tables.
  2. Using the result on Rows or Columns: In Tableau (and on the shelves in the xmetric app), a FIXED LOD can be placed directly onto the Rows or Columns shelf as a discrete dimension (for example, grouping customers by their cohort month). In Power BI, a DAX measure is evaluated dynamically in the report filter context and cannot be used directly as a grouping axis or slicer column; you must define a DAX Calculated Column or summary table first.

How can I translate an INCLUDE LOD into a DAX iterator?

When your visual shows Region on Rows and you want the average total order size per region, Tableau writes:

// Tableau / xmetric INCLUDE LOD
AVG({ INCLUDE [Order ID] : SUM([Sales]) })

In DAX, you must iterate over the distinct Order ID values within the current filter context using AVERAGEX and VALUES, triggering a context transition via CALCULATE:

Avg Order Value =
AVERAGEX(
    VALUES(Orders[Order ID]),
    CALCULATE(SUM(Orders[Sales]))
)

How do the platforms and their costs compare?

The native tools provide their own desktop and hosted workflows; xmetric provides browser-local file opening. Prices below come from each vendor’s cited page.

FeaturexmetricTableau DesktopMicrosoft Power BI
Authoring OS supportAny browser (Mac, Windows, Linux)Windows and macOS desktop appWindows-only for Power BI Desktop (Windows 10 / Windows Server 2016+)
Cost to author and view local filesFree in the browserFree local edition (one person, no publishing or sharing), free Tableau Public & Tableau Reader, or Creator at $75 per user/month, billed annuallyFree Power BI Desktop (Windows); Pro at $14.00 user/month, paid yearly or Premium Per User at $24.00 user/month, paid yearly to share
Calculation languageTableau LOD (FIXED, INCLUDE, EXCLUDE) & table calcs (in the app and the formula playground; does not run DAX)Tableau LOD & table calcsDAX & Power Query M
Inspects .twbx and .pbix / .pbip workbooksYes, in browser (inspector reads .twbx, .twb, .pbix, and zipped .pbip; .twbx / .twb also open in the app; Power BI visuals are not drawn)Yes (.twbx / .twb)Uses .pbix / .pbip (does not open .twbx)

When should I use Power BI or Tableau?

Choose the native platform when its model behavior, governance or hosted workflow is required.

  • Power BI for Microsoft shops. Choose Power BI if your organization runs on Windows and Microsoft 365 E5 (which includes Power BI Pro) and you rely on semantic star-schema models shared across Excel PivotTables and SharePoint.
  • DAX itself. If the formulas must run as DAX against a Power BI model, test them in Power BI. xmetric does not run DAX or draw Power BI visuals.
  • Tableau for governed servers. Choose Tableau Cloud/Server if you need enterprise server extract schedules and governed multi-department permissions.

When should I use xmetric?

Use xmetric to inspect local workbook definitions and check supported calculations in the browser. This does not establish complete native feature parity.

  • Check the LOD side. Run FIXED, INCLUDE, and EXCLUDE expressions on sample data and see the equivalent SQL in the formula playground, free on Mac, Windows, or Linux.
  • Audit before you rewrite. Drop a .twbx or .twb into the workbook inspector to list its formulas, or a .pbix or zipped .pbip to see its tables, DAX measures, relationships, and the fields each visual uses (DAX is read, not run).
  • Build on shelves. Open a .twbx / .twb or import a CSV, Excel, or Parquet file in the xmetric app and drag fields, including LOD calculations, onto Rows, Columns, and the Marks card.

Can I run Power BI Desktop natively on a Mac to test DAX formulas?

No, Microsoft Power BI Desktop is a Windows-only application. To test DAX, Mac users need a Windows virtual machine or the Power BI web service with a work tenant. xmetric runs in any browser but doesn't run DAX; you can inspect .pbix and .pbip files in the workbook inspector and run Tableau's LOD grammar in the formula playground.

Which is easier for an AI coding agent to verify: LOD, DAX, or SQL?

SQL is the most predictable for coding agents because GROUP BY and OVER (PARTITION BY ...) make the grain explicit without hidden filter-context transitions. In xmetric's formula playground, you can test LOD expressions alongside their SQL equivalents right in the browser.

How do I convert a nested FIXED LOD inside another FIXED LOD to DAX?

Break each nested { FIXED } block into its own DAX variable (VAR) using SUMMARIZE or ADDCOLUMNS at the inner grain, then aggregate over that virtual table variable with SUMX or AVERAGEX in the RETURN statement.

Run the LOD in the formula playground to pin down its grain before you write the DAX.

What data does this worked example use?

The initial view uses authored synthetic data, not customer data or a captured agent session.

The example record lists its file, calculation or SQL and expected values. The live browser result is computed by xmetric’s existing engine or workbook inspector. Samples are excluded from own-data activation reporting.