Causeway · Concepts

Semantic models: shared, certified, governed

Datasets are called semantic models now and the term matters. The canonical pattern for one model per domain, many thin reports, and how Databricks metric views close the double-definition problem.

"Datasets" are called semantic models in 2026, and the name change signals Microsoft's direction: these are first-class, shared, governed artifacts, not report-local afterthoughts. Teams that keep treating them as "the thing the report authors maintain alongside their report" keep having the same expensive conversation about why revenue looks different on three dashboards.

The canonical pattern

One semantic model per business domain, published to a gold-tier workspace, endorsed as Certified or Promoted, consumed by many thin reports via live connection.

workspaces/
  sales-semantic-gold/
    sales_model             ← shared, Certified
  finance-semantic-gold/
    finance_model           ← shared, Certified

  sales-reports/
    account-health.pbix     ← live connection to sales_model
    pipeline.pbix           ← live connection to sales_model
    regional-qbr.pbix       ← live connection to sales_model

  finance-reports/
    p-and-l.pbix            ← live connection to finance_model
    budget-v-actual.pbix    ← live connection to finance_model

Report authors do not embed their own model. They connect to the shared one and build visuals.

The failure mode this prevents

The failure mode is predictable and expensive: "revenue" defined in one dashboard as SUM(amount), in another as SUM(amount) - SUM(refunds), in a third as SUM(amount) * fx_rate. Each of the three definitions was correct to the author at the time. None of them agree.

Shared semantic models make this a review concern, not a discovery-at-board-meeting concern. The measure lives in one place, is version-controlled, is reviewed by domain owners, and is endorsed once.

Important

One shared semantic model per domain is not a starting guideline. It is the end state every mature Power BI practice lands on. Start there; do not let report-local models proliferate and plan to consolidate later. The consolidation never happens.

Endorsement

Power BI endorsement levels, in increasing trust:

LevelMeaning
NoneDefault; user-authored, not reviewed
PromotedTeam-level endorsed; use within the team
CertifiedOrganization-level endorsed; use anywhere

Certification is a real governance event. It requires a named owner, a review cadence, and a documented rollback path. Causeway domains run one Certified semantic model each; everything else is Promoted or unendorsed.

Databricks metric views

In 2026 Databricks metric views ship BI Compatibility Mode, which lets Power BI call metric views with standard SQL aggregation functions. This is the first time metric definitions have been able to live in one place and be consumed identically by Databricks SQL and Power BI.

The pragmatic pattern:

-- Databricks metric view
CREATE METRIC VIEW prod.gold.sales_metrics AS
SELECT
    customer_id,
    region,
    product_category,
    transaction_date,
    SUM(amount_usd)    AS total_revenue_usd,
    COUNT(DISTINCT order_id) AS order_count
FROM prod.gold.fct_orders
GROUP BY 1, 2, 3, 4;

Power BI connects to sales_metrics, treats total_revenue_usd as an aggregatable column, and gets the same semantics wherever it is used.

Automatic aggregations

For DirectQuery and Direct Lake semantic models, Power BI can build automatic aggregations on top of the fact tables. It watches query patterns, materializes the top-N aggregation tables in memory, and serves matching queries from cache.

Enable it on any DirectQuery semantic model with more than a few hundred million fact rows. It is free performance if the model is shaped right (star schema, surrogate keys, narrow facts).

Tip

Automatic aggregations are not magic. They work when the underlying model is a clean star. If your fact has calculated columns, bidirectional relationships, or snowflaked dims, the aggregations Power BI builds will be subtly wrong in ways the developer notices last. Fix the model shape first; then turn on auto-aggregations.

Thin reports

A report that connects to a shared semantic model is called "thin" because it carries no model of its own. The authoring experience changes:

This separation is how you make BI authoring a plausibly-parallelizable activity. Ten report authors can work simultaneously; one or two modelers own the semantic model.

Ownership review

The hardest part of shared semantic models is the social half. Measures accumulate, owners drift, and "certified" becomes noise unless you review it on a cadence.

The cadence that works:

Semantic Layer (dbt Semantic Layer, OSI)

Two adjacent standards are worth being aware of:

See also