Using Shared Datasets — Use a shared dataset / semantic model to build a report (intro)

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.

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.

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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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).

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.

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.

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.

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.

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.