Historical Context & Motivation
In the early days of business intelligence, every report author typically built their own data connections, transformations, and measure definitions from scratch. This approach created a proliferation of conflicting metric definitions—one team's 'revenue' figure might differ from another's because of subtle differences in filters, exchange-rate logic, or date-boundary handling. The resulting inconsistencies eroded trust in BI platforms and forced organizations to invest heavily in manual reconciliation. Microsoft Power BI addressed this challenge by introducing the concept of a shared dataset (now formally called a semantic model), enabling multiple reports to connect to one authoritative, curated data layer. This paradigm shift mirrors the evolution from ad-hoc SQL scripts to centralized data warehouses in traditional analytics—only now it operates at the self-service BI layer, empowering report authors without sacrificing governance.
The fundamental question that shared datasets answer is deceptively simple: how do we ensure that every report in the organization computes 'total revenue,' 'active users,' or 'churn rate' the same way? Without a shared semantic layer, each report author re-implements these definitions independently, and subtle discrepancies inevitably emerge. By centralizing the data model, relationships, and DAX measures in a single published semantic model, Power BI transforms the problem from one of distributed consistency—notoriously difficult in computer science—into a straightforward architectural pattern of a single source of truth.
Core Principles & Definitions
Understanding shared datasets in Power BI requires grasping several interrelated concepts that together form the architecture of a governed, scalable BI environment. At the center is the semantic model—the analytical engine that stores tables, relationships, hierarchies, and business logic. Around it, connection modes, workspace permissions, and endorsement mechanisms control who can consume the model and how.
Semantic Model
Live Connection
Build Permission
Endorsement (Promoted / Certified)
Thin Reports
Visual Explanation — Architecture Overview
The following diagram illustrates the shared dataset architecture in Power BI. At the center, a single semantic model connects upstream to data sources and downstream to multiple thin reports. Notice how the model owner publishes and governs the semantic model in a workspace, while report authors in separate workspaces create reports that reference it via live connections.
The critical insight from this architecture is the separation of concerns between data modeling and report authoring. The model owner—typically a data engineer or analytics engineer—maintains the semantic model's schema, relationships, and DAX measures. Report authors, who may be business analysts or domain experts, focus exclusively on building visualizations and crafting narratives. This division of labor is analogous to the front-end/back-end split in web development: the API team guarantees correct data, and the UI team consumes it to build user experiences. Neither team needs to duplicate the other's work.
How It Works — Connection Mechanics
When you build a report on top of a shared semantic model, the underlying protocol is XMLA (XML for Analysis), the same protocol that Analysis Services has used for decades. Power BI Desktop and the Power BI Service both issue DAX queries against the remote Analysis Services engine hosting the semantic model. The report file (.pbix or .rdl) itself stores only the visual definitions, page layouts, filters, and the connection string pointing to the published model—it contains zero rows of data.
Step-by-Step: Connecting to a Shared Semantic Model
- Discover the model. In Power BI Desktop, navigate to Home → Get Data → Power BI semantic models (or 'Power BI datasets' in older versions). Alternatively, in the Power BI Service, click '+ New report' from the semantic model's context menu.
- Authenticate and authorize. Power BI validates your Azure AD (Entra ID) credentials and checks whether you hold Build permission on the target model. If you lack this permission, the model will not appear in the picker.
- Establish a live connection. Power BI creates an XMLA endpoint connection to the hosted semantic model. The local .pbix file records this connection string and stores no data locally.
- Author visuals. You drag fields and measures from the Fields pane (populated by the remote model) onto the canvas. Each visual generates a DAX query sent to the model at render time.
- Publish the thin report. Publish the .pbix to any workspace. The report retains its live connection to the original semantic model, even if it lives in a different workspace.
Under the hood, Power BI's query engine translates each visual into a DAX query, serializes it as an XMLA request, and sends it to the Analysis Services instance hosting the semantic model. The engine evaluates the query against the in-memory columnar storage (VertiPaq) or proxies it to the underlying source (DirectQuery), then returns the result set. This mechanism is transparent to the report author—visuals simply render the returned data. The performance characteristics, however, differ based on whether the semantic model uses Import mode (data cached in VertiPaq, fast but periodic refresh) or DirectQuery mode (queries forwarded to the source in real time, slower but always current).
Detailed Workflow & Data Hub Discovery
The Power BI data hub (sometimes called the OneLake data hub) is the primary discovery interface for shared semantic models. It aggregates all semantic models, dataflows, and other data items the user has access to, surfacing endorsement status, owner information, refresh schedules, and usage metrics. Understanding how to navigate this hub efficiently is essential for report authors who need to identify the right model before building a report.
Discovering the right semantic model is a non-trivial step in enterprise environments where dozens or hundreds of models may exist. The data hub's filtering capabilities—by workspace, endorsement status, and keyword—help narrow the search. Pay particular attention to the Certified badge: it signifies that a Power BI admin or designated data steward has verified the model's data quality, measure correctness, and documentation. Models labeled Promoted have been recommended by their workspace owners but have not undergone formal certification review. In a well-governed organization, report authors should default to Certified models unless a specific use case requires a different dataset.
Worked Example — Building a Report on a Shared Model
Suppose your organization's data team has published a Certified semantic model called Enterprise Sales Model in the 'Analytics Hub' workspace. It contains tables for FactSales, DimProduct, DimDate, and DimCustomer, along with DAX measures such as [Total Revenue], [Gross Margin %], and [YoY Growth]. You need to build a quarterly sales performance report for the executive team.
Enterprise Sales Model is established. The Fields pane populates with all tables and measures.[Total Revenue] and [Gross Margin %] appear as measures (denoted by a calculator icon).DimDate[Quarter] to the Y-axis and [Total Revenue] to the X-axis. Add DimProduct[Category] to the Legend well to segment revenue by product category. The visual immediately queries the remote semantic model and renders the results.FactSales table and select 'New measure.' Enter the DAX: Revenue per Customer = DIVIDE([Total Revenue], DISTINCTCOUNT(FactSales[CustomerKey])). This measure exists only in your report file and does not modify the shared model.[Revenue per Customer] is now available for visuals in this report only.Enterprise Sales Model in the 'Analytics Hub' workspace is preserved. Any user with access to both the report and the underlying model can now view the dashboard.Strengths & Limitations of Shared Semantic Models
Like any architectural pattern, shared semantic models introduce trade-offs. Understanding these trade-offs is crucial for deciding when to use a shared model versus embedding a local dataset in your report.
| Dimension | Strengths | Limitations |
|---|---|---|
| Consistency | Single source of truth for metrics. All reports compute measures identically. | If the shared model contains an error, it propagates to all connected reports simultaneously. |
| Governance | Endorsement, Build permission, and RLS provide layered access control and quality signals. | Requires organizational discipline to maintain endorsement labels and documentation. |
| Performance | Model is loaded once in memory; multiple reports reuse the same engine instance, reducing total resource consumption. | Heavy concurrent usage from many reports can cause resource contention on shared capacity. Premium or Fabric capacity may be required. |
| Flexibility | Report authors can add report-level measures without modifying the core model. | Cannot add tables, relationships, or calculated columns at the report level. Schema changes require the model owner. |
| Maintainability | Fix a measure once; all reports inherit the fix. Dramatically reduces maintenance burden. | Breaking schema changes (e.g., renaming a column) can break downstream reports if not coordinated. |
Connection to Advanced Concepts
Shared semantic models serve as the foundational building block for several advanced Power BI and Microsoft Fabric features. As you progress, you will encounter patterns that extend the basic live-connection paradigm into more sophisticated architectures. Understanding how this introductory concept maps to those advanced features will help you plan scalable BI solutions.
| Introductory Concept | Advanced Extension | Key Difference |
|---|---|---|
| Live connection to a single semantic model | Composite models | Allows adding local Import tables alongside the remote model, enabling mashups without duplicating the core model. |
| Report-level measures | Calculation groups | Centrally defined DAX templates (e.g., YTD, MTD, PY) that apply to any measure, managed at the model level via Tabular Editor. |
| Endorsement (Promoted / Certified) | Purview integration | Microsoft Purview extends governance with data lineage visualization, sensitivity labels, and cross-platform cataloging. |
| Import / DirectQuery modes | Direct Lake mode | In Microsoft Fabric, Direct Lake reads Parquet files directly from OneLake—no import needed, yet queries run at near-Import speeds. |
| Manual publish from Desktop | Deployment pipelines (CI/CD) | Manages Dev → Test → Prod stages with automated rules, parameter swaps, and approval gates for both models and reports. |
The most important advanced extension to be aware of is composite models. While a pure live connection restricts you to the remote model's schema, composite models let you add local Import or DirectQuery tables that join to the shared model's tables via relationships you define. This is analogous to extending a base class in object-oriented programming: you inherit the core functionality (shared measures, relationships) while adding domain-specific data (a local spreadsheet, a departmental database) at the report level. However, composite models introduce additional complexity around data staleness and security boundaries, so they should be used judiciously.
Practice Problems
[Avg Order Value] defined as DIVIDE([Total Revenue], [Order Count]), but this measure does not exist in the shared model. Describe how you would add this measure, explain its scope, and discuss the implications if the model owner later adds a measure with the same name to the shared model.Summary
A shared semantic model in Power BI is a centrally published data layer containing tables, relationships, and DAX measures that serves as a single source of truth for metric definitions across an organization. Report authors connect to it via live connections, producing lightweight thin reports that contain only visuals and layouts—no embedded data. This separation of concerns mirrors established software engineering patterns: the semantic model is the API, and reports are the consumers.
Governance is enforced through Build permissions (controlling who can author reports against the model), endorsement labels (Promoted and Certified, signaling data quality), and row-level security (restricting data visibility per user). Report authors retain flexibility through report-level measures and can extend the pattern further with composite models. This architecture reduces redundancy, ensures consistency, and scales gracefully as the number of reports grows.