Are Your Tableau LOD Expressions Too Complex to Touch?

FIXED, INCLUDE and EXCLUDE are precise tools for genuine multi grain questions. Most of the ones in your workbook are there because the warehouse never resolved the grain or kept the history.

Are Your Tableau LOD Expressions Too Complex to Touch?

The data warehouse automation platform trusted by data teams across industries

Does this sound familiar?

  • A workbook has a dozen FIXED expressions and removing any one of them breaks a view.
  • Calculations slow down sharply as soon as a second data source is blended in.
  • You are using LOD to reconstruct what a value was at a point in time.
  • Nobody but the original author will touch the calculation tab.

Level of Detail expressions are the right answer to a genuine multi grain question. They are also where the fix goes when the data arrives at the wrong grain, and that second kind is what makes a workbook fragile.

What the LOD expressions are standing in for

  • A point in time state. FIXED plus date logic, rebuilding history the source overwrote.
  • A missing dimension. FIXED on a concatenated key, because there is no real one to join on.
  • Two grains in one table. EXCLUDE to undo duplication that a proper fact table would never have created.
  • A relationship with no bridge. INCLUDE doing the work of a bridge table.

Each evaluates at query time, per view, and blending across sources multiplies the cost.

Why it lands on you

  • Every one of these was the fastest route to a correct number that week.
  • They are invisible to anyone outside the workbook, so they cannot be reviewed or reused.
  • You can restructure the calculation. You cannot add the dimension it is substituting for.

The work is in the wrong place

  • History, keys and grain are warehouse work. In LOD expressions they are rebuilt for every view.
  • It belongs in one central place: a data warehouse or data hub, built once and read by every workbook.
  • If that sounds expensive, the estimate probably assumes hand built pipelines. A specialised automation platform generates them from a model, which changes both the cost and the time it takes.

What changes when the model arrives finished

Datavault Builder resolves grain, keys and history in the warehouse, on Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol or PostgreSQL.

  • Point in time tables answer “as at March” with a join, not an expression.
  • Bridge tables resolve many to many before Tableau connects.
  • Explicit surrogate keys, so relationships replace concatenated string matching.
  • One grain per fact table, which removes most EXCLUDE work outright.
  • What remains are genuine LOD questions, and they are short enough for a colleague to read.

What to ask for

“These LOD expressions are rebuilding point in time state and resolving grain at query time. Can the warehouse give us a PIT table and a single grain fact table, so the calculations become plain aggregations?”

That distinguishes the LOD you actually need from the LOD you are using as a patch.

See It Working on Your Own Data

Book a free demo and bring the report that gives you the most trouble.

Three Steps to Numbers That Add Up

  1. Extract the existing logic

    Collect the calculations, joins and filters that live in your reports today.

  2. Centralize it in one place

    The logic moves into the warehouse model once, so every report reads the same definition.

  3. Enjoy numbers that add up

    Every report shows the same figure, and “where did this number come from” has a visible answer.

How Datavault Builder Hands Your Report a Finished Model

  • The model arrives finished

    Datavault Builder generates the vault and the star schema to run natively in the database you already have: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks or BigQuery.

  • The work leaves the report

    No merge, no parsing, no fuzzy match. That work is gone from the report.

  • Sources arrive integrated

    Customers from the ERP, the CRM and the web shop are matched into one set of conformed dimensions. The join happens once in the warehouse, not again in every report.

  • History you can query

    Every change is retained as it arrives, so you can report as-was as well as as-is, even where the source system overwrites its own records.

  • Every number has lineage

    The logic gains lineage, so “where did this number come from” has a visible answer.

  • Changes handled upstream

    Slowly changing dimensions are handled upstream as vault satellites, not approximated.

Recognized by BARC in The Data Fabric Survey 26

Meet Our Expert

Twenty minutes with our Sales Director, and an honest answer on whether this fits your situation.

Matt Collett

Matt Collett

Sales Director

What are you looking for?

By submitting you agree to our Privacy Policy.

Other Problems This Series Covers

  • Does Your Tableau Server Have Too Many Versions of the Same Number?

    Every published .tdsx was reasonable on the day it was made. Together they are hundreds of private definitions of the same metric, and no way to tell which one is right.

  • Do Your Tableau Extract Refreshes Keep Failing or Running Late?

    The backgrounder times out, the .hyper file keeps growing, and the dashboard shows yesterday. The extract is large because it is carrying raw rows that were never aggregated upstream.

  • Is Your Tableau Dashboard Slow Every Time You Change a Filter?

    Twenty seconds of “Executing Query” on every filter click. Tableau is not rendering slowly. It is waiting for a database that was handed a question it cannot answer quickly.