Connecting to Shared Semantic Models

In the early days of business intelligence, every report was a silo. If you needed a sales report, you would connect to a database, write your queries, transform the data, build your calculations, and then design your charts. If your colleague needed a slightly different version of that sales report, they would often start from scratch, repeating those same steps. This approach inevitably led to "multiple versions of the truth," where two reports supposed to show the same metric—like "Total Revenue"—displayed different numbers because the underlying logic or data refresh timing differed.

Shared semantic models solve this fundamental problem. A semantic model is a logical layer that sits between your raw data sources and your visual reports. It contains the data connections, the transformation logic, the relationships between tables, and the complex business logic defined in calculations. By "sharing" this model, an organization creates a single, authoritative source of truth. Instead of every report author building their own data pipeline, they simply connect to a "Golden Dataset" that has already been vetted, cleaned, and secured by data experts.

Connecting to shared semantic models is the cornerstone of a mature data culture. It moves the organization away from fragmented reporting and toward a "hub-and-spoke" architecture. In this lesson, we will explore the mechanics of connecting to these models, the different connection modes available, how to manage permissions, and the best practices for building reports that remain performant and easy to maintain over time.

Understanding the Architecture of Shared Models

Before we dive into the "how," we must understand the "what." In modern BI tools like Power BI, a semantic model is essentially a database that lives in the cloud. It is optimized for analytical queries (OLAP) rather than transactional processing (OLTP). When you connect to a shared model, you aren't importing the data into your local file; instead, you are creating a bridge to a model that is already hosted in a workspace.

This architecture creates a clear separation of concerns. The data engineers and modelers focus on the "upstream" work: data ingestion, cleansing, and defining complex DAX (Data Analysis Expressions) measures. The report authors focus on the "downstream" work: data visualization, storytelling, and user experience. This separation makes the entire reporting ecosystem more agile. If a business rule changes—for example, the way "Gross Margin" is calculated—the modeler updates it once in the shared semantic model, and every report connected to it updates automatically.

Callout: The Concept of the "Thin Report"

A "Thin Report" is a report file (typically a .pbix file) that contains no data of its own. Instead, it contains only the visual layer—the charts, tables, and slicers—and a live connection pointer to a shared semantic model. These files are incredibly small in size (often only a few hundred kilobytes) because they don't store the underlying rows of data. This makes them easy to version control, share, and manage, as the heavy lifting of data storage and processing is handled by the cloud service.

Connection Modes: Live Connection vs. DirectQuery

When you connect to a shared semantic model, you generally have two primary ways to interact with it. Understanding the difference between these two is critical for your report's performance and flexibility.

1. Live Connection

A Live Connection is the simplest and most common way to use a shared model. In this mode, your report is a direct window into the model. You can see all the tables, columns, and measures defined by the modeler, but you cannot change the structure of the data. You cannot add new tables, you cannot merge data from other sources, and you cannot edit the relationships between existing tables.

The primary advantage of a Live Connection is simplicity and performance. Because you aren't adding any complexity to the model, the report behaves exactly as the modeler intended. It is the preferred method for standard corporate reporting where consistency is the highest priority.

2. DirectQuery for Power BI Datasets (Composite Models)

For years, Live Connection was the only option. However, modern BI platforms introduced a more flexible approach known as "DirectQuery for Power BI datasets." This allows you to treat a shared semantic model as if it were a raw data source.

In this mode, you can connect to a shared model and then "mash it up" with other data. For example, you could connect to the corporate "Sales" model and then import a local Excel file containing your team's specific targets. This creates a "Composite Model." While powerful, this adds a layer of complexity and can impact performance, as the engine now has to coordinate queries between the shared model and your local data.

Note: When using DirectQuery for shared models, you are essentially creating a new local model that "wraps" the remote model. This requires careful management of relationships to ensure that the local data joins correctly with the remote dimensions.

Step-by-Step: Connecting to a Shared Model

Connecting to a shared model is designed to be an intuitive process, but there are specific steps you should follow to ensure you are connecting to the right version of the data.

Step 1: Discovering the Model

In Power BI Desktop, you start by selecting "Power BI datasets" (often found under the "Get Data" or "Data Hub" menu). This opens a discovery window that shows you all the models you have permission to access.

You shouldn't just pick the first model with a familiar name. Look for "Endorsement" labels. Organizations often use two types of endorsements:

• Promoted: These models are flagged by authors as being ready for general use.
• Certified: These are the "gold standard" models that have been reviewed and verified by a central data governance team. Always prioritize Certified models for official reporting.

Step 2: Establishing the Connection

Once you select a model and click "Connect," Power BI Desktop establishes a Live Connection. You will notice that the "Data" and "Model" views on the left-hand sidebar disappear or become limited. This is normal; because you are in a Live Connection, you are not managing the data structure locally.

Step 3: Verifying the Connection

Look at the bottom right corner of your screen. You should see a status bar that says "Connected live to the Power BI dataset: [Model Name]." This confirms that your report is successfully tethered to the cloud-hosted model.

Step 4: Building the Visuals

You can now drag fields from the "Fields" pane onto your canvas. Note that you can create "Report-Level Measures." These are DAX calculations that live only in your report and do not change the underlying shared model.

// Example of a Report-Level Measure
// This measure calculates a 10% 'What-If' increase on top of an existing shared measure
Target Growth = [Total Sales] * 1.10

In the example above, [Total Sales] is a measure that exists in the shared model. You are simply referencing it to create a new calculation specific to your report's needs.

Permission Requirements and Security

You cannot connect to a shared model simply because you know it exists. Security is handled through a layered permission model. To connect to a shared semantic model, you typically need two specific permissions:

1. Read Permission: This allows you to see the data in the model and view reports built on top of it.
2. Build Permission: This is the critical requirement for creating new reports. Build permission allows you to use the model as a data source for other reports, use it in the "Analyze in Excel" feature, or connect to it via the XMLA endpoint.

Warning: If you share a report with a colleague but they do not have at least "Read" permission on the underlying shared semantic model, they will see an error message stating they don't have access to the data. Shared models require you to manage permissions for both the report file and the dataset itself.

Row-Level Security (RLS)

One of the greatest benefits of using shared models is that Row-Level Security (RLS) is inherited. If the modeler has set up RLS so that a Regional Manager can only see sales for their specific region, those rules automatically apply to your report. You don't have to do anything to enforce this security; the shared model handles it at the source. This ensures that no matter how many reports are built on top of the model, the data remains secure and restricted to the appropriate users.

Best Practices for Using Shared Models

To get the most out of shared semantic models, you should follow industry-standard best practices. These ensure that your reports are scalable, maintainable, and easy for others to understand.

1. Avoid "Model Bloat" in Thin Reports

Even though you can create report-level measures, use this feature sparingly. If you find yourself creating the same measure in five different "thin reports," that is a sign that the measure should be moved into the central shared model. Always aim to keep the logic as close to the data as possible.

2. Use Clear Naming Conventions

When you connect to a shared model, you are stuck with the names the modeler chose for tables and columns. However, when you create your own report-level measures, make sure they are clearly named. Avoid generic names like "Measure 1" or "Calculation A." Use descriptive names like "Variance to Budget (Local)" to distinguish your local calculations from the central ones.

3. Monitor the Lineage

Most BI platforms provide a "Lineage View." This is a visual map that shows which reports are connected to which models. Before you make significant changes to a report, or if you are a modeler planning to update a shared model, check the lineage view. This helps you perform an "Impact Analysis" to see who will be affected by your changes.

4. Leverage the Data Hub

The Data Hub (or similar discovery portals) is your friend. Instead of searching through workspaces, use the hub to find models. Use the metadata provided—such as the description, the owner, and the last refresh date—to ensure the model is actually what you think it is.

Common Pitfalls and How to Avoid Them

Even seasoned professionals run into trouble with shared models. Here are the most common mistakes and how to steer clear of them.

Pitfall 1: The "Read-Only" Frustration

New users often get frustrated when they realize they can't change a data type or rename a column in a Live Connection.

• The Fix: If the data structure is truly wrong, you must contact the owner of the shared model to fix it at the source. This is a feature, not a bug—it ensures that everyone is using the same definitions. If you only need a temporary fix for one report, consider using a Composite Model, but be aware of the added complexity.

Pitfall 2: Version Mismatch

Sometimes, a modeler might update a shared model with a new version of the BI software, or they might change a measure name that your report relies on.

• The Fix: Always maintain a line of communication with the model owner. If you are the model owner, use the "Endorsement" and "Description" fields to warn users of upcoming changes. For report authors, if your visuals suddenly break with a "Fix this" error, the first place to check is whether a field in the underlying model was renamed or deleted.

Pitfall 3: Over-reliance on Report-Level Measures

It is tempting to build dozens of measures in your thin report because it's faster than asking the central team to update the model.

• The Fix: This leads to "logic drift." If your calculation is useful for the whole department, advocate for its inclusion in the master model. This reduces your maintenance burden and helps your colleagues.

Pitfall 4: Ignoring Refresh Schedules

Just because your report is "Live" doesn't mean the data is real-time. The "Live" part refers to the connection between your report and the model, not the model and the original data source.

• The Fix: Check the refresh schedule of the shared model. If the model only refreshes once a day at 8:00 AM, your report will show that same data all day, regardless of how many times you refresh your browser.

Callout: Performance in Composite Models

When you use DirectQuery to connect to a shared model and then add your own data, you are creating a "Chain." If you connect to Model A, and Model A is already a DirectQuery connection to a SQL Database, you now have a chain of three layers. Every time a user clicks a slicer, the query has to travel through all those layers. This can significantly slow down your report. Always try to keep your chains as short as possible.

Advanced Scenario: Cross-Tenant Sharing

In larger organizations or B2B scenarios, you might need to connect to a shared semantic model that lives in a completely different "tenant" (a different corporate account). This is common during mergers or when working with external consultants.

This process involves "B2B Guest Users." The hosting organization must invite you as a guest and grant you "Build" permissions on the model. Once invited, you can connect to their model using the tenant URL. While the workflow is similar to internal sharing, be mindful of data privacy regulations. Data that leaves its home tenant may be subject to different compliance rules, so always consult your IT security team before establishing cross-tenant connections.

Industry Standards and the "Hub-and-Spoke" Model

The use of shared semantic models is the primary driver of the "Hub-and-Spoke" BI governance model.

• The Hub: A central team (Center of Excellence or IT) manages the core, certified semantic models. They ensure data quality, security, and performance.
• The Spokes: Individual business units (Marketing, Finance, Operations) build their own "thin reports" on top of those hub models. They can also create their own "specialized" models for niche use cases, perhaps mashing up hub data with their own departmental data.

This model is considered the industry standard because it balances the need for central control with the need for business agility. It prevents the "Wild West" of data where everyone has their own version of the numbers, but it also avoids the "IT Bottleneck" where business users have to wait weeks for a simple report change.

Managing the Lifecycle of Shared Models

As a report author, you are a consumer of a service. As a modeler, you are a service provider. Managing the lifecycle of a shared model requires a different mindset than managing a single report.

Versioning and Development

You should never make "live" changes to a shared model that is currently being used by hundreds of reports. Instead, use a development and staging environment. Many platforms offer "Deployment Pipelines" that allow you to move a model from Development to Test and finally to Production.

Impact Analysis

Before hit the "Publish" button on an update to a shared model, use the "Impact Analysis" tool. This tool will tell you exactly how many reports and how many unique users will be affected by your change. If you are deleting a column that is used by 50 reports, you need to notify those 50 report owners in advance.

Tip: If you must rename a field in a shared model, consider creating a "calculated column" with the old name that simply points to the new name. This acts as a "deprecated" field, giving report authors time to update their reports before you eventually delete the old name entirely.

Practical Example: The Sales and Marketing Mashup

Let's look at a real-world scenario. The Corporate IT team maintains a Certified Sales Model. This model contains millions of rows of transaction data, complex currency conversions, and official product hierarchies.

The Marketing team wants to analyze how a specific social media campaign impacted sales. The social media data is in a CSV file from an external agency.

1. The Wrong Way: The Marketing analyst downloads the Sales data into Excel, tries to join it with the CSV, and creates a pivot table. This is slow, the data is immediately stale, and the currency conversion logic is likely wrong.
2. The Right Way: The Marketing analyst opens Power BI Desktop and connects to the Certified Sales Model using DirectQuery. They then "Import" the social media CSV. They create a relationship between the CampaignDate in the CSV and the Date table in the shared Sales model.

The result is a highly accurate, performant report that uses official sales figures but includes the specific marketing insights they need. When the IT team updates the Sales model next month, the Marketing report automatically benefits from those updates without any extra work from the analyst.

Summary and Key Takeaways

Connecting to shared semantic models is a shift in how we think about data. It requires moving away from individual ownership and toward a communal, governed ecosystem. While it requires more coordination and a deeper understanding of permissions and connection modes, the rewards are immense: consistency, security, and a massive reduction in duplicated effort.

By mastering these connections, you position yourself as a sophisticated data professional who understands how to build scalable BI solutions. You move from being a "report builder" to being a "data architect" who understands the flow of information across an entire organization.

Key Takeaways:

• Single Source of Truth: Shared semantic models eliminate data silos by providing a central, vetted source for all reporting, ensuring that key metrics remain consistent across the organization.
• Thin Reports are Efficient: By separating the visual layer from the data layer, you create "thin reports" that are small, easy to manage, and simple to version control.
• Choose the Right Connection: Use Live Connection for maximum performance and consistency when you only need the shared model. Use DirectQuery (Composite Models) when you need to mash up shared data with local sources.
• Permissions Matter: You need both Read and Build permissions to create new reports from a shared model. Security rules like RLS are automatically inherited, protecting data at the source.
• Prioritize Endorsed Content: Always look for Certified or Promoted models in the Data Hub to ensure you are building on a reliable foundation.
• Communicate and Analyze Impact: Use lineage views and impact analysis to understand the relationship between models and reports. If you are a modeler, communicate changes; if you are a report author, stay informed of the model's refresh schedule and updates.
• Logic Should Live Upstream: Avoid creating complex logic in individual reports. If a calculation is useful for more than one report, it belongs in the shared semantic model.