INCLUDE/EXCLUDE LOD — Use INCLUDE/EXCLUDE LOD to control granularity

Before Tableau introduced Level of Detail (LOD) expressions in version 9.0, analysts faced a persistent problem: the granularity of every calculation was dictated solely by the dimensions present in the visualization. If your view displayed data at the product level, every aggregation—SUM, AVG, COUNT—was computed at the product level, with no straightforward way to reference a different grain. Workarounds existed—table calculations, data blending, custom SQL—but each introduced complexity, performance overhead, or fragility that made dashboard maintenance burdensome. For anyone accustomed to writing GROUP BY clauses in SQL, this limitation felt particularly constraining, because SQL lets you freely control the grouping level of any subquery or window function. LOD expressions were Tableau's answer to that gap, and the INCLUDE and EXCLUDE keywords gave analysts declarative control over which dimensions participate in an aggregation, independent of the view.

The central question that INCLUDE and EXCLUDE LOD expressions address is deceptively simple: how do you compute a metric at a different level of granularity than what is currently displayed, and then seamlessly blend it back into the view? Understanding the answer requires a precise mental model of how Tableau's query pipeline processes dimensions, aggregations, and filters—and that is exactly what this lesson develops.

To wield INCLUDE and EXCLUDE LOD expressions effectively, you need to internalize a few foundational concepts about how Tableau constructs queries. Every visualization in Tableau implicitly defines a view-level granularity—the set of dimensions currently on the Rows, Columns, Color, Size, Detail, and Tooltip shelves. This view-level granularity determines the GROUP BY clause of the underlying query. LOD expressions let you override that implicit grouping by explicitly adding or removing dimensions from the aggregation context.

The following diagram illustrates how INCLUDE and EXCLUDE modify the aggregation grain relative to the view. The center column represents the view-level granularity—the dimensions currently on the shelves. INCLUDE shifts the computation to a finer grain (more dimensions), while EXCLUDE shifts it to a coarser grain (fewer dimensions). After the LOD calculation runs at its specified grain, the result is mapped back to the view through re-aggregation or replication.

Notice the critical distinction in the lower boxes. When INCLUDE computes at a finer grain, there are more intermediate rows than the view requires, so Tableau must wrap the LOD result in an outer aggregation—typically AVG(), MIN(), or MAX()—to collapse the extra rows back to the view level. Conversely, when EXCLUDE computes at a coarser grain, there are fewer intermediate rows, so the coarser result is simply replicated (broadcast) to each row at the view grain. This behavior directly parallels how SQL window functions replicate partition-level aggregates across row-level results.

Understanding the SQL that Tableau generates from LOD expressions demystifies their behavior. Consider a view with [Region] and [Category] on the shelves. The view-level grain is GROUP BY Region, Category. An INCLUDE expression adds a dimension to that GROUP BY, while an EXCLUDE expression removes one. Tableau materializes the LOD computation as a subquery or common table expression (CTE) and then joins it back to the main query.

Generated SQL Analogy

For a view with dimensions [Region] and [Category], an INCLUDE expression like { INCLUDE [Product] : SUM([Sales]) } generates a subquery equivalent to:

Choosing between INCLUDE and EXCLUDE depends on whether you need to drill deeper than the view or pull back to a broader perspective. In practice, the choice often maps to a specific analytical pattern: INCLUDE is ideal when you need per-entity metrics before summarizing (e.g., average order size per customer, then averaged across regions), while EXCLUDE shines when you want each row to reference a parent-level total (e.g., category sales as a share of regional total). The following diagram maps common analytical scenarios to the appropriate LOD type.

Suppose you have a Superstore-style dataset and a bar chart showing SUM([Sales]) per [Region]. Your goal is two-fold: (1) compute the average sales per customer in each region using INCLUDE, and (2) compute the percentage of total sales each region represents using EXCLUDE.

Strengths of INCLUDE/EXCLUDE

• ✓ View-adaptive: Both INCLUDE and EXCLUDE automatically adjust their effective grain when you add or remove dimensions from the view. This makes dashboards more maintainable than FIXED-based approaches for view-relative calculations.
• ✓ Filter-respecting: Because they sit after dimension filters in the pipeline, INCLUDE and EXCLUDE respect the user's filter selections—a behavior that analysts usually expect.
• ✓ Composable: You can nest LOD expressions inside other calculations, use them in IF statements, or combine INCLUDE and EXCLUDE results in a single formula.

Limitations and Pitfalls

• Outer aggregation confusion: INCLUDE results must be wrapped in an outer aggregation. Forgetting this—or using the wrong one—is the most common source of errors. AVG, MIN, and MAX produce very different results.
• Performance with high cardinality: INCLUDE on a high-cardinality dimension (e.g., Customer ID with millions of distinct values) forces Tableau to compute a much larger intermediate result set, which can degrade query performance.
• EXCLUDE on the last dimension: If you EXCLUDE the only dimension in the view, the grain becomes the entire dataset. This is valid but can be confusing to interpret.

INCLUDE and EXCLUDE LOD expressions form the foundation for several advanced analytical patterns in Tableau. Once you have mastered the basic mechanics, you can compose these expressions to handle complex, multi-grain calculations that would otherwise require custom SQL or data model changes. The following table contrasts basic usage with advanced patterns that build on the same principles.

As you move toward more sophisticated Tableau development—building parameter-driven dashboards, implementing row-level security, or designing reusable calculated fields—the ability to reason about grain management becomes indispensable. LOD expressions are, at their core, a way to declaratively manage grain in a visual analytics environment. This concept maps directly to dimensional modeling principles (Kimball methodology), where fact tables exist at specific grains and bridge tables mediate between grains. If you continue into data engineering or analytics engineering (e.g., dbt, LookML), you will encounter the same grain-management challenges at the modeling layer, and the mental model you build here transfers directly.