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.
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 RevenueorChurn 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:
| Component | What it does | Example |
|---|---|---|
| Tables and columns | Data loaded or queried from sources, with data types, formats and descriptions | Sales, Customer, Date |
| Relationships | Define how filters flow between tables | Sales[CustomerKey] to Customer[CustomerKey] |
| Measures (DAX) | Calculations evaluated at query time in the context of each visual and filter | Net Revenue, Gross Margin % |
| Calculated columns and tables | DAX expressions stored as data at refresh time | An age band column on Customer |
| Hierarchies | Drill paths for report users | Year, quarter, month, day |
| Roles (RLS and OLS) | Row-level and object-level security that limit what each user can see | Regional 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:
| Mode | How it reads data | Trade-off |
|---|---|---|
| Import | Copies data into the model's in-memory storage at scheduled or manual refresh | Fastest queries, but data is only as fresh as the last refresh |
| DirectQuery | Sends a query to the source, such as Snowflake or Databricks, on every user interaction | Current data, but performance depends on the source |
| Direct Lake | Loads columns on demand from Delta tables in Fabric OneLake; a refresh copies only metadata | Import-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.
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.
| Aspect | Power BI semantic model | Warehouse or standalone semantic layer |
|---|---|---|
| Examples | Power BI and Fabric semantic models | dbt Semantic Layer, Snowflake semantic views, Databricks metric views |
| Definition language | DAX, stored as TMDL or model metadata | YAML or SQL DDL |
| Main consumers | Power BI reports, Excel, Copilot, Fabric agents | SQL clients, BI tools through connectors, warehouse AI features |
| Query language for clients | DAX and MDX through XMLA | SQL or a semantic layer API |
| Security | RLS and OLS roles in the model | Warehouse grants, row filters and masks |
| Reach | Power BI and Fabric, plus XMLA and MCP clients | The 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
.pbixor.pbitfile, 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
- Microsoft Learn - New name for Power BI datasets
- Microsoft Learn - Semantic model modes in the Power BI service
- Microsoft Learn - Direct Lake overview
- Microsoft Learn - Use composite models in Power BI Desktop
- Microsoft Learn - Endorsement overview
- Microsoft Learn - Semantic model permissions
- Microsoft Learn - Semantic model connectivity and management with the XMLA endpoint
- Microsoft Learn - Tabular Model Definition Language (TMDL)
- Microsoft Learn - Prepare your data for AI
- Microsoft Learn - Semantic model best practices for data agent
- Microsoft Learn - What is Fabric IQ?
- Microsoft Learn - Get started with the Fabric IQ MCP server
- Microsoft Learn - Semantic link and Power BI connectivity
- Microsoft Learn - Power BI semantic models in Microsoft Fabric
- Snowflake - Creating semantic views with Snowsight
- Databricks - Connect metric views to Power BI (November 2026)
- Dawiso Help - Power BI integration
- Dawiso Help - Ingest from Power BI workspace XMLA endpoint
See it in action
Business Glossary
Clear context is essential to ensure everyone interprets terms consistently and accurately.