Using Power BI Semantic Models Across Workspaces - One Model, Many Reports

Here's a pattern I see in almost every Australian organisation that's been running Power BI for more than a year or two. Finance has a workspace with a sales model in it. Operations built their own sales model because they didn't know Finance had one. Marketing copied Finance's PBIX file six months ago, changed a few measures, and now the two versions disagree about last quarter's revenue in front of the executive team. Nobody did anything wrong exactly. The tooling just made duplication the path of least resistance.

The fix has been sitting in the product for years, and it's still underused: semantic models can be consumed across workspace boundaries. You build and certify one model in a workspace the data team controls, and report authors all over the business connect to it live from their own workspaces. One version of the truth, many reports on top. Microsoft documents the mechanics in use semantic models across workspaces, and this post is about how to actually run the pattern, because the mechanics are the easy bit.

What cross-workspace consumption actually gives you

When a report author in Power BI Desktop or the service goes looking for data, the OneLake catalog (formerly the datahub) shows them semantic models they have access to across the whole tenant, not just their own workspace. They pick one, get a live connection, and build their report wherever they like. The report lives in the marketing workspace; the model stays in the analytics workspace. Refresh, security, and model changes all remain with the model's owners.

That separation is the whole point. The people who understand the data model, the DAX, and the row-level security rules are rarely the same people who need to knock up a report for Thursday's meeting. Cross-workspace models let each group do their job without stepping on the other.

A few pieces make the pattern work in practice:

Build permission. Viewing a report only needs read access. Creating a new report on someone else's semantic model needs Build permission on that model. You can grant it directly on the model, through an app audience, or it comes implicitly with member and admin workspace roles. This is the single most misunderstood part of the whole feature, and I'll come back to it.

Endorsement. Models can be marked as promoted or certified. Certification is the strong signal - it's controlled by tenant admins, who delegate the ability to certify to specific people or groups. When a report author searches for data, certified models float to the top with a badge. Without endorsement, the catalog is just a big pile of models with similar names, which is arguably worse than no catalog at all.

Lineage view. Because reports and their models now live in different workspaces, you need a way to see what depends on what. Lineage view in each workspace shows the connections, including the cross-workspace ones. Check it before you touch anything.

Why this matters more than it looks

The honest version of the business case is boring: it's about trust and rework, not features.

Every duplicated model is a future reconciliation meeting. When two reports disagree, someone senior stops trusting both, and once executives stop trusting the numbers, they go back to asking an analyst to pull figures manually, which quietly destroys the ROI on the whole platform. We've done Power BI consulting engagements where the actual deliverable, once you got past the stated brief, was collapsing eleven versions of the same customer model into one certified one. The DAX took a fortnight. The politics took a quarter.

There's also a straightforward cost angle. Duplicated Import models mean duplicated refreshes, duplicated memory on your capacity, and duplicated maintenance every time a source column changes. On Premium or Fabric capacities, that's real money. One shared model with a solid incremental refresh policy is cheaper in every way that counts, and if you're already heading down the Fabric path, the same shared-model discipline carries straight over - it's a big part of what our Microsoft Fabric consultants end up setting up for clients as part of workspace architecture.

How we set it up for clients

The shape that works, and which we now recommend by default:

Put shared semantic models in dedicated workspaces owned by the data team, separate from any reports. Names like "Sales - Semantic Models" are dull and perfect. Report workspaces belong to business areas and contain reports only, or close to it.

Grant Build permission through security groups, not to individuals. Individual grants rot as people move roles. A group called something like "Sales Model - Report Builders" is auditable and survives staff turnover.

Certify sparingly. Two or three certified models that people genuinely trust beat thirty certified models where the badge has stopped meaning anything. Set up the certification process so it involves an actual review - if certification is a rubber stamp, you've just invented a more official way to be wrong.

Treat the model like an API. This is the mindset shift that matters most. Once ten reports across four workspaces depend on your model, renaming a measure is a breaking change. Deleting a column is a breaking change. The data team needs deprecation habits: check lineage, communicate, give people a release cycle to adjust. Teams that treat the shared model like their private sandbox generate a steady stream of Monday-morning broken reports and burn exactly the trust the pattern was supposed to build.

The sharp edges

Now the stuff the documentation is polite about.

Build permission confusion will generate support tickets. A user can see a report built on a shared model, try to duplicate it or create their own, and get an unhelpful permission error because they have read access but not Build. Expect this, write the two-line explainer before the tickets arrive, and decide up front who's allowed to grant Build and how people request it.

Copying a report does not copy understanding. The service lets people copy reports across workspaces against the same shared model, which is handy, but the copy inherits none of the context about what the measures mean. A data dictionary or even a well-maintained description on the model does more for correct usage than any amount of governance policy.

Live connections limit the report author. Connecting live to a shared model means the report author can't add their own data sources or Power Query steps in that report. They can create report-level measures, and that's roughly it. For most consumers that's fine, and honestly it's half the point. For the analyst who needs to mash the certified model together with their own spreadsheet, the answer is a composite model using DirectQuery for Power BI semantic models. It works, and it's matured a lot, but it adds a layer of complexity and some performance characteristics you want to understand before it spreads through the organisation. Allow it deliberately, not by accident.

Deleting things is now dangerous. A model owner who deletes or moves a model can break reports in workspaces they've never seen. Lineage view is your friend; so is a rule that nothing certified gets deleted without a lineage check.

The tenant switch. There's an admin setting controlling whether semantic models can be used across workspaces at all. In most tenants it's on, but if the catalog looks strangely empty for your users, start there rather than debugging permissions for an hour. Ask me how I know.

Where to start

If your Power BI estate has grown organically, don't try to boil the ocean. Pick the one subject area that causes the most number-disagreement pain - it's usually sales or revenue - and build or nominate a single model for it. Certify it, grant Build to the right groups, and pick one team's reports to migrate onto it. Once that team stops arguing about numbers, the pattern sells itself internally and the next migration is easier.

The reporting layer is also where a lot of AI work lands these days - natural language over data, agents that answer questions from the model - and all of it inherits the quality of the semantic layer underneath. An agent sitting on top of five conflicting sales models gives you five conflicting answers with more confidence. If that's the direction you're heading, our AI for business intelligence work covers exactly this intersection, and step one is almost always the same: get to one model worth trusting.

The feature itself is mature and unglamorous. That's a compliment. Shared semantic models are one of the few governance mechanisms in Power BI that make the right thing easier than the wrong thing, and most organisations are one dedicated workspace and a certification badge away from using them properly.