Semantic Models

What it is

A semantic model defines the tables, relationships, measures (DAX), hierarchies, and security that BI consumers see. In Fabric, the semantic model is the contract between the engineering team that owns Gold-tier tables and the reporting team that visualizes them.

Done well, one semantic model serves dozens of reports, hundreds of users, and the Data Agent for natural-language Q&A. Done poorly, each report becomes its own model and the same KPI is defined seventeen different ways.

Direct Lake mode

Direct Lake is the headline storage mode for Fabric. The model reads Delta-Parquet files in OneLake column-by-column on demand. No import refresh. No DirectQuery latency. When the upstream Lakehouse or Warehouse changes, Power BI sees the change seconds later.

Direct Lake has constraints: certain DAX functions trigger fallback to DirectQuery, table sizes have practical ceilings (improving rapidly), and calculated columns over Direct Lake have edge cases. The Fabric team has been closing these aggressively through 2025–2026, but check the current limits when designing.

DAX patterns that scale

• Time intelligence via a dedicated date dimension, not USERELATIONSHIP gymnastics.
• Variables for reusable expressions: name them, document them, and reuse across measures.
• Calculation groups for time-period comparisons (MTD, YTD, PY) to avoid measure proliferation.
• Field parameters to let users pick the measure or dimension from a slicer.
• Implicit measures off: every value displayed comes from a named, explicit measure.

Row- & object-level security

RLS uses DAX expressions on roles to filter what rows a user sees. OLS hides entire tables or columns from selected users. Both live on the model — never re-implement them in reports.

• Static RLS: roles like "US Only" with hardcoded filters. Simple.
• Dynamic RLS: USERPRINCIPALNAME() joined to a user-territory bridge table. Scales.
• Hierarchical RLS: managers see their direct reports' data; cascade via PATH/PATHCONTAINS over a parent-child table.
• OLS for sensitive columns: salary, customer PII, margin-on-cost — hide from non-authorized roles entirely.

Build accelerator

1. Start from the Gold tables. Star schema, surrogate keys, conformed dimensions. The model design follows the data model.
2. Build in Tabular Editor. Free, fast, source-controllable. TMDL files diff cleanly in Git.
3. Run Best Practice Analyzer in CI. Adopt a custom ruleset that fails the build on common anti-patterns.
4. Wire RLS at the model. Test with the "View as role" feature; document the truth table.
5. Promote via deployment pipelines. Parameterize the workspace source between dev/test/prod.
6. Endorse the model. Certify it in the OneLake Catalog so users find it and don't build copies.

Best practices

• One model per business domain, not per report.
• Hide foreign keys, surrogate keys, and any field a report author shouldn't touch.
• Format and category every measure (currency, percent, decimal places).
• Use display folders to organize measures by analysis area.

Common pitfalls

Related items