Skip to main content
power bi semantic modelpower bi datasetDAX measuresDirect LakeMicrosoft Fabricshared semantic modelsemantic layerFabric IQ

What Is a Power BI Semantic Model (Formerly Dataset)?

A Power BI semantic model is the published model behind Power BI reports: the tables, relationships, DAX measures, hierarchies and security roles that turn raw data into business numbers such as revenue, margin or active customers. Until November 2023 Microsoft called it a dataset. Every report, Excel PivotTable, Copilot answer or AI agent connected to the same semantic model reads the same measures, so the model is where a Power BI number gets its meaning.

A semantic model lives as an item in a Power BI or Microsoft Fabric workspace. It is usually authored in Power BI Desktop, saved in a .pbix file or a Power BI Project, and published to the service, where other people can build reports on it without copying the logic.

TL;DR

A Power BI semantic model, the item Microsoft renamed from "dataset" in November 2023, stores tables, relationships, DAX measures and row-level security. It reads data in Import, DirectQuery or Direct Lake mode, can be shared and certified so many reports reuse one model, and is the context that Copilot, Fabric data agents and Fabric IQ use to answer questions. Its definitions are written in DAX and computed by the Power BI engine, and dbt, Snowflake and Databricks cannot reuse them, so a metric that also exists in dbt, Snowflake or Databricks needs an approved business definition above all of them.

What Is a Power BI Semantic Model?

A Power BI semantic model is a tabular data model, built on the same engine as Analysis Services, that sits between data sources and the reports people read. Microsoft renamed the dataset content type to semantic model for two reasons it states in its documentation: "dataset" had become too generic once Power BI was one of many experiences in Microsoft Fabric, and the new name better reflects what the model does. Microsoft describes the change as a rename only, with no change in behavior, so older articles, APIs and community posts that say "dataset" describe the same thing.

In practice a semantic model answers three questions for every report built on it:

  • Which data is in scope: the tables and columns loaded or queried from sources such as a Fabric lakehouse, a SQL database, Snowflake or Databricks.
  • How the data fits together: relationships between fact and dimension tables, usually arranged as a star schema.
  • What the numbers mean: measures written in DAX, such as Net Revenue or Churn Rate, with their formats and descriptions.

How to design a good model, from star schemas to calculated columns, is covered in our Power BI data modeling guide. This article is about the semantic model as an object: what it contains, how it reads data, how it is shared, and where its reach ends.

What Is Inside a Power BI Semantic Model?

A semantic model combines data with the business logic needed to read it correctly. The main parts are:

ComponentWhat it doesExample
Tables and columnsData loaded or queried from sources, with data types, formats and descriptionsSales, Customer, Date
RelationshipsDefine how filters flow between tablesSales[CustomerKey] to Customer[CustomerKey]
Measures (DAX)Calculations evaluated at query time in the context of each visual and filterNet Revenue, Gross Margin %
Calculated columns and tablesDAX expressions stored as data at refresh timeAn age band column on Customer
HierarchiesDrill paths for report usersYear, quarter, month, day
Roles (RLS and OLS)Row-level and object-level security that limit what each user can seeRegional managers see only their region

Measures are the part most people mean when they talk about "the definition" of a metric. A simple example:

Net Revenue =
SUM ( Sales[GrossAmount] )
    - SUM ( Sales[DiscountAmount] )
    - SUM ( Sales[ReturnAmount] )

The formula is stored once in the model and evaluated for whatever filters a report applies: by region, by month, by product. Every report on the model gets the same calculation. The function library behind such formulas is covered in the Power BI DAX functions guide, and the security roles in Power BI row-level security.

Since Microsoft introduced TMDL (Tabular Model Definition Language) and Power BI Projects, a semantic model can also be saved as readable text files and kept in Git, which lets teams review a change to a measure the same way they review code.

Semantic Model Storage Modes

Every table in a semantic model has a storage mode, which decides whether the data is copied into the model or queried where it lives. Microsoft documents three main modes:

ModeHow it reads dataTrade-off
ImportCopies data into the model's in-memory storage at scheduled or manual refreshFastest queries, but data is only as fresh as the last refresh
DirectQuerySends a query to the source, such as Snowflake or Databricks, on every user interactionCurrent data, but performance depends on the source
Direct LakeLoads columns on demand from Delta tables in Fabric OneLake; a refresh copies only metadataImport-like speed without a full copy, available only in Microsoft Fabric

A model that mixes storage modes across tables, including Dual tables that can act as either Import or DirectQuery, is a composite model. Direct Lake has two variants, Direct Lake on OneLake and Direct Lake on SQL, and the SQL variant can fall back to DirectQuery in some cases, for example when a table is a SQL view. How Direct Lake and OneLake change capacity planning is covered in Power BI Fabric integration.

One Fabric change worth knowing: since September 5, 2025, Fabric no longer creates a default semantic model automatically for every new warehouse, lakehouse or mirrored item, and by November 30, 2025 existing default models became independent items. Teams now create the semantic models they need on purpose, which is good for governance because each model is an item someone chose to build and own.

How a Power BI Semantic Model Works HOW A POWER BI SEMANTIC MODEL WORKS DATA SOURCES Fabric OneLake (Delta tables) SQL databases Snowflake, Databricks Files and SaaS apps Where the data lives SEMANTIC MODEL Tables and relationships DAX measures Hierarchies, formats, descriptions RLS and OLS roles Import, DirectQuery or Direct Lake Defined once, reused by every report CONSUMERS Power BI reports and apps Excel PivotTables Copilot and Fabric data agents Fabric IQ MCP clients XMLA tools and notebooks Same measure in every tool BEYOND THE POWER BI BOUNDARY Approved business definitions, owners, and lineage for the same metrics in dbt, Snowflake and Databricks The cross-platform context layer
Click to enlarge

Shared and Certified Semantic Models

A semantic model becomes valuable when many reports share it. Instead of each analyst importing the same tables and rewriting the same measures in their own .pbix file, a team publishes one model and others connect to it. Microsoft calls this a shared semantic model, and it is the main way Power BI avoids "two reports, two numbers".

  • Live connection. A report author in Power BI Desktop or the service connects to a published model and builds visuals on its measures without copying them. This needs Build permission on the model.
  • Composite models on a shared model. An author can extend a published model with their own tables or measures through DirectQuery for Power BI semantic models, without editing the original.
  • Endorsement. Fabric and Power BI items can carry one of three badges. Promoted means the creators think the model is ready to reuse, Certified means an authorized reviewer confirmed it meets the organization's quality standards, and Master data marks an item as the authoritative source for core data. Endorsed models appear first when people look for data to build on.
  • XMLA endpoint. On Premium, Premium Per User and Fabric capacities the model is exposed through an XMLA endpoint, read-only by default and read/write when an admin enables it. Tools such as Tabular Editor, SQL Server Management Studio and deployment scripts use it to read or change the model, and Write permission is needed to make changes.

Endorsement tells people which model to use. It does not record what a measure is supposed to mean in business terms, who in finance agreed with the formula, or whether the same metric is defined differently somewhere else in the company. Those questions belong to a business glossary.

How Copilot, AI Agents and Other Tools Use a Semantic Model

The semantic model is the context Microsoft's AI features read. When someone asks Copilot in Power BI a question, the answer is computed from the measures and relationships in the model, which is why Microsoft recommends preparing the model before people rely on Copilot answers.

  • Prep data for AI (in preview as of November 2026) adds three things to a model: an AI data schema that limits which tables, columns and measures Copilot may use, verified answers that return an approved visual for specific questions, and AI instructions with business terminology. Verified answers are stored on the semantic model, so they apply to every data agent that uses it.
  • Fabric data agents can use a semantic model as a data source and generate DAX queries against it. See Power BI Copilot for the report-side experience.
  • Fabric IQ names the semantic model as one of its two core items, next to the ontology, which was labeled preview in Microsoft's documentation as of November 2026.
  • Fabric IQ MCP is a read-only MCP server, generally available as of November 2026, that lets MCP clients that support its Microsoft Entra sign-in find Power BI reports and semantic models, inspect their metadata and run DAX queries. It applies the caller's existing permissions, and RLS and OLS still restrict what is returned. A separate Power BI authoring MCP server, available as a local server or, in preview as of November 2026, a hosted endpoint, lets an agent create and change models.
  • Excel and notebooks. Analyze in Excel builds PivotTables on the model's measures, and semantic link in Fabric notebooks lets data scientists list and evaluate measures from Python instead of rewriting them.

All of these consumers get consistent numbers because they read one model. They also inherit its blind spots: if Net Revenue in the model differs from net revenue in the finance warehouse, Copilot will repeat the model's version confidently.

Power BI Semantic Model vs Semantic Layer

A Power BI semantic model is a BI-native semantic layer: it defines metrics for the tool that owns it. The general concept is explained in what is a semantic layer, and other platforms have their own versions.

AspectPower BI semantic modelWarehouse or standalone semantic layer
ExamplesPower BI and Fabric semantic modelsdbt Semantic Layer, Snowflake semantic views, Databricks metric views
Definition languageDAX, stored as TMDL or model metadataYAML or SQL DDL
Main consumersPower BI reports, Excel, Copilot, Fabric agentsSQL clients, BI tools through connectors, warehouse AI features
Query language for clientsDAX and MDX through XMLASQL or a semantic layer API
SecurityRLS and OLS roles in the modelWarehouse grants, row filters and masks
ReachPower BI and Fabric, plus XMLA and MCP clientsThe warehouse or project that hosts it

Neither kind replaces the other in most US enterprise stacks. dbt or the warehouse often holds the cleaned data and some metric logic, and Power BI still needs a semantic model for its reports. How to split definitions between them is the subject of our post on where business definitions should live.

Where a Power BI Semantic Model Stops

A semantic model is very good at making Power BI consistent. Three things sit outside its scope:

  • Definitions outside Microsoft. DAX measures are read by Power BI, Excel, Fabric and XMLA clients. A dbt model, a Snowflake semantic view or a Databricks metric view cannot use them directly. The bridges that exist translate definitions into a new copy: Snowflake can generate a semantic view from a .pbix or .pbit file, Snowflake's Apache Ossie quickstart converts a semantic view into a Power BI model, and Databricks can publish metric views to Power BI as semantic models (private preview as of November 2026), dropping measures that do not meet its requirements. Each translation is useful, and each one leaves two definitions that can drift.
  • Business ownership. A model has a technical owner and can be certified, but neither records the agreed business meaning of a measure or the person accountable for it. That is the job of a business glossary with named owners.
  • End-to-end lineage. Fabric shows lineage between its own items. Tracing a Power BI number back through dbt transformations to a source system needs data lineage that crosses platforms.

This is the gap a context layer fills: one governed record of what each metric means, who owns it and where it is implemented, across Power BI and everything else. The difference is explained in context layer vs semantic layer.

How Dawiso Works With Power BI Semantic Models

Dawiso's Power BI connector scans workspaces, semantic models (listed as datasets), their tables, columns and measures, reports, dashboards and dataflows. For each measure it records the DAX expression and format string, and for dataflows it records endorsement and sensitivity labels. Semantic models can also be scanned through a workspace XMLA endpoint with a service principal. Scanning is read-only metadata, so no report data is copied.

On top of that metadata, the Dawiso Business Glossary holds the approved definition of each business term or indicator, such as net revenue, with a named business owner and steward, and the term can be related to the Power BI measure that implements it and to other scanned objects such as dbt models, Snowflake tables and views, or Databricks metric views. Dawiso builds lineage from platform scans and from dbt, and SQL parsing for supported databases can be enabled with Dawiso Customer Success, so the tables behind a semantic model can be traced toward their sources. AI tools that support MCP, such as Claude and Cursor, can query Dawiso through the Dawiso MCP Server: they can search objects, read their attributes, such as a glossary term's definition and workflow state, and trace lineage.

Conclusion

A Power BI semantic model is the single place where Power BI keeps tables, relationships, DAX measures and security, and sharing and certifying it is the best way to give every report, Copilot answer and Fabric agent the same number. Its reach is the Microsoft estate. When the same metric also lives in dbt, Snowflake or Databricks, the model should implement an approved business definition rather than be the only record of it.

Sources

See it in action

Business Glossary

Clear context is essential to ensure everyone interprets terms consistently and accurately.

A cookie a day keeps bad UX away.

We use cookies to personalize content, ads and to analyze our traffic. We also share information about your use of our site with our advertising and analytics partners who may combine it with other information that you've provided to them or that they've collected from your use of their services. By clicking "Accept All", you allow us to use cookies for analytics and ads via Google Tag Manager. You can also customize cookies.

Customize Consent Preferences

We use cookies to personalize content, ads and to analyze our traffic. We also share information about your use of our site with our advertising and analytics partners. Privacy Policy

Necessary cookies allow core website functionality such as user login and account management. The website cannot be used properly without strictly necessary cookies.

Functionality cookies are used to remember visitor information on the website, eg. language, timezone, enhanced content.

Analytics cookies are used to see how visitors use the website, eg. analytics cookies. Those cookies cannot be used to directly identify a certain visitor.

We use Microsoft Clarity to see how you use our website (including heatmaps and session replays) so we can improve it. By using our site, you agree that we and Microsoft can collect and use this data. See our Privacy Policy for details.

Advertisement cookies are used to identify visitors between different websites, eg. content partners, banner networks. Those cookies may be used by companies to build a profile of visitor interests or show relevant ads on other websites.