Snowflake semantic views get FIXED, INCLUDE and EXCLUDE LOD metrics

Snowflake has added level of detail (LOD) expressions to semantic views, in Preview, according to a release note dated November 2, 2026. An LOD expression calculates a value at a grain that differs from the grain of the query, so a semantic view can now carry metrics such as a share of the regional total, a grand-total denominator or an average of per-customer counts without the analyst rewriting the logic in every query or dashboard.

The feature has three forms that BI developers will recognize from other semantic layers and from Tableau calculations: FIXED DIMENSIONS pins a calculation to an exact set of dimensions, INCLUDE DIMENSIONS adds dimensions to the query grain for one calculation, and EXCLUDE DIMENSIONS removes them. Snowflake's documentation marks the section as a preview feature available to all accounts, and it lists one important gap. Cortex Analyst and Cortex Agents do not use LOD metrics yet, so for now they work only in SQL queries against semantic views and in Semantic Studio in Snowsight.

··········

WHAT SNOWFLAKE ANNOUNCED FOR SEMANTIC VIEWS.

The release note describes LOD expressions as a way to compute a value at a different grain from the query's grain. They can be defined in the FACTS, DIMENSIONS and METRICS clauses of CREATE SEMANTIC VIEW, or in the model-level facts, dimensions and metrics keys of the YAML specification for semantic views. The documentation on defining LOD metrics, part of the guide to managing semantic views with SQL, gives the syntax, the filter rules and a set of restrictions.

The practical effect is that a calculation which used to live in a window function, a subquery or a BI tool's own calculated field can be defined once in the semantic view. Every consumer that queries the view through SQL then receives the same number, which reduces the risk of two dashboards showing two different "percent of total" values for the same slice of data. The Databricks counterpart, covered in our article on relationships between Unity Catalog metric views, follows the same idea of moving business logic out of individual reports.

........

Item	Status as documented
LOD expressions in semantic views	Preview, release note of Nov 2, 2026
Account availability	All accounts, per the documentation
SQL queries with SEMANTIC_VIEW	Supported
Semantic Studio in Snowsight	Supported
Cortex Analyst and Cortex Agents	Not supported yet
Edition or extra privileges	Not stated for LOD metrics
Pricing	No separate pricing published

........

··········

HOW FIXED, INCLUDE AND EXCLUDE DIMENSIONS WORK.

Each LOD clause follows an aggregate expression. FIXED DIMENSIONS computes the aggregate at exactly the listed dimensions, whatever the query groups by; an empty list, written as FIXED DIMENSIONS (), produces a grand total that works as a denominator. INCLUDE DIMENSIONS computes the aggregate at the query grain plus the listed dimensions, which is the tool for averages of finer-grained values. EXCLUDE DIMENSIONS computes it at the query grain minus the listed dimensions, which gives coarser totals such as a regional figure next to a category-level value.

The documentation allows LOD calculations to be defined as facts, as dimensions or inline inside a metric. When an LOD is written inline, it sits inside an outer aggregate. The definitions below follow the documented syntax with illustrative names; they are fragments of the FACTS and METRICS clauses of a semantic view built on an orders table and a customers table.

-- in FACTS
orders_per_customer AS COUNT(orders.order_id)
  FIXED DIMENSIONS (customers.customer_id),

grand_total_revenue AS SUM(orders.order_amount)
  FIXED DIMENSIONS (),

-- in METRICS
avg_orders_per_customer AS AVG(orders_per_customer),

pct_of_regional_total AS SUM(orders.order_amount) /
  AVG(SUM(orders.order_amount) EXCLUDE DIMENSIONS (orders.category))

The query side does not change. A consumer selects dimensions and metrics through the SEMANTIC_VIEW construct, and the semantic view resolves the grain of each LOD calculation.

SELECT * FROM SEMANTIC_VIEW(
  sales_sv
  DIMENSIONS customers.region
  METRICS avg_orders_per_customer
)
ORDER BY region;

··········

THE RULES THAT LIMIT LOD METRICS IN SNOWFLAKE.

The documentation lists several restrictions that a semantic model designer has to plan around. LOD names are referenced without an entity prefix, which is why the metric above reads AVG(orders_per_customer). LOD calculations are always aggregated. One LOD calculation cannot reference another, and an aggregate can reference only one LOD calculation. The dimension lists of FIXED, INCLUDE and EXCLUDE accept only defined facts or dimensions that are themselves not LOD calculations.

There are also limits on where the results can be used. LOD dimensions and LOD metrics cannot be used in materializations. In a query, INCLUDE and EXCLUDE calculations can be referenced only in METRICS, as the sole argument of an aggregate function, and never in DIMENSIONS or FACTS. A FIXED calculation defined as a dimension can be queried in the DIMENSIONS clause. Finally, an LOD expression cannot be written inline in a SEMANTIC_VIEW query. It has to be defined in the semantic view first, so ad hoc grain changes still require an edit to the model.

··········

FILTERS CHANGE THE RESULT OF FIXED AND EXCLUDE METRICS DIFFERENTLY.

The most consequential rule for dashboard builders concerns filters. For FIXED calculations, Snowflake applies the filter after the LOD calculation, so the value reflects all the underlying data before rows are removed. For INCLUDE and EXCLUDE calculations, the filter is applied before the LOD calculation, so the value reflects only the rows that survive the filter. The documentation shows this with a WHERE clause on a SEMANTIC_VIEW query: the FIXED metric keeps the full regional total while the EXCLUDE metric shrinks to the filtered customer.

The small dataset below is illustrative and was built to show the arithmetic. Four customers place eight orders across two regions and two product categories, for a grand total of $2,250. The expected results were computed in Python and cross-checked with a standard SQL query, so a team testing the preview can compare Snowflake's output against known values.

........

Region	Category	Revenue	Regional total (EXCLUDE category)	Share of region	Share of grand total (FIXED ())
North	Hardware	$750	$1,300	57.7%	33.3%
North	Software	$550	$1,300	42.3%	24.4%
South	Hardware	$500	$950	52.6%	22.2%
South	Software	$450	$950	47.4%	20.0%

........

On the same data, the FIXED fact orders_per_customer gives three orders for customer C1, two for C2, two for C3 and one for C4. The metric avg_orders_per_customer therefore returns 2.5 for North and 1.5 for South when the query groups by region, and 2.0 when the query has no DIMENSIONS clause. Now add a filter that keeps only customer C1, who is in North. A FIXED regional total defined at the region grain still returns $1,300 for North, because the filter is applied after the calculation, while a regional total built with EXCLUDE returns $800, the revenue of C1 alone.

Teams that want to validate the preview against their warehouse tables can reproduce the share calculations with ordinary window functions. The query below ran locally on the illustrative data and returned the percentages shown in the table.

WITH base AS (
  SELECT c.region, o.category, SUM(o.order_amount) AS revenue
  FROM orders o
  JOIN customers c ON c.customer_id = o.customer_id
  GROUP BY c.region, o.category
)
SELECT
  region,
  category,
  revenue,
  SUM(revenue) OVER (PARTITION BY region) AS regional_total,
  ROUND(100.0 * revenue / SUM(revenue) OVER (PARTITION BY region), 1) AS pct_of_regional_total,
  ROUND(100.0 * revenue / SUM(revenue) OVER (), 1) AS pct_of_grand_total
FROM base
ORDER BY region, category;

··········

WHAT BI TEAMS SHOULD CHECK BEFORE USING LOD METRICS.

The first check is the consumer. Because Cortex Analyst and Cortex Agents do not use LOD metrics yet, a semantic view that serves both SQL users and natural-language questions will answer differently depending on the entry point: the SQL path can return the LOD metric, while the AI path cannot use it. Teams that connect AI assistants to Snowflake, as in the workflows described in our pieces on Snowflake CoCo for Google Sheets and Tableau Data Apps, should document which metrics are LOD-based and keep a non-LOD fallback where an assistant needs one.

The second check is filter semantics. Analysts used to window functions or to BI tools with their own context rules may expect a filtered total where Snowflake returns an unfiltered FIXED value, or the reverse. Naming conventions help here: a suffix that marks FIXED metrics, and a short description in the semantic view, make it clear to report authors that the number ignores the query's WHERE clause.

The third check is operational. LOD calculations cannot be materialized, so performance on large tables depends on how the query is executed, and the documentation does not publish performance guidance for the preview. The feature is also in Preview, which means syntax and behavior can still change before general availability; production dashboards that depend on it should be retested when Snowflake updates the release notes.

··········

SNOWFLAKE LOD METRICS: WHAT IS DOCUMENTED AND WHAT IS STILL OPEN.

Snowflake's documentation confirms the three LOD forms, their placement in FACTS, DIMENSIONS and METRICS or in the YAML specification, the filter order for FIXED versus INCLUDE and EXCLUDE, the restrictions on nesting, materialization and query clauses, and support in SQL queries and Semantic Studio. It also states that the preview is available to all accounts.

What depends on the customer's setup is the consumer path: SQL clients and Snowsight can use LOD metrics today, while Cortex Analyst and Cortex Agents cannot. What Snowflake has not disclosed is a date for general availability, a date for Cortex support, any edition requirement specific to the feature and any performance guidance. For data teams moving metric logic into a governed layer, the preview is ready for testing on known datasets like the one above, with the filter behavior of FIXED metrics as the first thing to verify.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org