Building Power BI Reports on Shared Semantic Models Across Workspaces
Here is a scene I have watched play out at more than one Australian business. The sales team has a revenue number. Finance has a revenue number. They are different. Nobody can explain why, so a meeting gets booked, and three people spend an hour discovering that one report counts revenue at invoice date and the other counts it at payment date. Both are defensible. The problem is that two teams built two separate models with two separate definitions of the same word, and now the whole business quietly distrusts every dashboard.
The fix for this is not a better meeting. It is a shared semantic model. Build the data model once, define revenue once, and have every report across the business connect to that same model instead of rebuilding it. Microsoft calls the mechanism for this discovering and reusing semantic models across workspaces, and their documentation walks through the clicks. What the docs don't tell you is why this is one of the most important architectural decisions you will make in Power BI, and where it gets awkward in practice.
The core idea: one model, many reports
The old way people build Power BI is to make each report self-contained. Every report has its own copy of the data, its own relationships, its own measures. It feels natural because that is how Power BI Desktop works out of the box: import your data, build your model, make your report, publish. One neat package.
The trouble is that the package doesn't scale. Report number two needs the same customer table, so someone rebuilds it. Report number three needs revenue, so someone writes the DAX again, slightly differently. Six months later you have fifteen reports, fifteen copies of roughly the same data, and fifteen subtly different answers to the same question. Refreshes multiply, the source database gets hammered fifteen times over, and no two numbers quite agree.
A shared semantic model breaks that pattern. You build the model as its own object, published to a workspace, and then reports connect to it live. The report holds no data of its own. It is a thin layer of visuals sitting on top of a central model. When you need a new report, you don't rebuild anything, you point at the model that already exists and start dragging fields.
How discovery across workspaces actually works
The bit the documentation is genuinely useful for is the mechanics of finding a model that lives in a different workspace to the one you are working in. In a real organisation, your central model probably lives in a governed workspace owned by the data team, and the people building reports work elsewhere. They need to discover and connect to that model without it being dumped in their laps.
Power BI handles this through the data hub, the place where you browse semantic models you have access to across the tenant, regardless of which workspace they sit in. From Power BI Desktop you connect to a published semantic model with a live connection; in the service you can build a report directly from a model you find in the hub. Either way, the report you create is linked to that central model, not a copy of it.
The endorsement side matters here too. A model that has been marked as certified or promoted shows up more prominently and signals to report builders that this is the sanctioned version, the one blessed by whoever owns the data. In a big tenant with lots of models floating around, endorsement is how people tell the real one from someone's abandoned experiment. If you are running a shared-model approach, actually use endorsement. An unendorsed sprawl of models is only marginally better than the copy-everything mess you were trying to escape.
The permission that catches everyone: Build
Now the part that generates support tickets. To create a report on top of someone else's semantic model, you need Build permission on that model. Not read, not access to the workspace, Build specifically. This is a distinct permission and it exists for a good reason: it controls who can create new content from your data, which is not the same as who can view a report you already made.
The confusion is constant. A report author can open and view a dashboard just fine, then tries to build their own report from the underlying model and hits a wall, because viewing and building are governed separately. The person who owns the model has to grant Build permission before anyone downstream can create against it.
My advice: think about Build permission as part of your model design, not as an afterthought. When you publish a central model that is meant to be reused, decide up front who should be able to build on it, and grant it deliberately, ideally to a group rather than a pile of individuals so you are not re-granting it every time someone new joins. Getting this governance right from the start is a lot of what our Power BI consultants focus on, because Build permission set up badly is either a bottleneck, where everything funnels through one admin, or a free-for-all where anyone can build anything.
What this unlocks, honestly assessed
The upside of shared semantic models is real and I am a fan. One definition of every metric. One refresh feeding many reports instead of many refreshes hammering the source. A clear separation between the people who own the data model and the people who build reports on top, which lets each group do their job without stepping on the other. When a metric definition changes, you change it once and every report updates. That last point alone justifies the whole approach.
But I will be straight about the rough edges, because they are worth knowing before you commit.
The first is that a live connection to a shared model is more constrained than owning your own. Report authors can add their own measures in some scenarios, but they can't freely restructure the model or add tables that aren't in it. If your report builders are used to importing whatever they like and modelling it themselves, the shared approach feels restrictive at first. That restriction is the point, it is what keeps the numbers consistent, but it is a genuine change in how people work and worth naming early.
The second is that a shared model makes the model owner a bottleneck if you are not careful. Every report now depends on the central model, so a bad change to that model breaks everything downstream at once. This raises the stakes on the model, which is exactly why the content lifecycle habits, a proper dev-test-prod path for the model itself, matter so much once you go down this road.
The third is a governance point. As soon as models are discoverable across workspaces, people can find and build on models they perhaps shouldn't. Row-level security and Build permission need to be handled deliberately, because discoverability without governance is just a faster way to leak data to the wrong audience.
Where to start if you are drowning in report copies
If you recognise your own environment in the two-different-revenue-numbers story, the path out is not dramatic. Pick your most important, most argued-about subject area, revenue, customers, whatever your business fights about most, and build one solid semantic model for it. Endorse it. Grant Build permission to the people who need it. Then rebuild your key reports as thin reports connected to that model, and retire the duplicate models as you go.
You do not have to migrate everything at once. Doing one subject area properly and proving that the numbers finally agree is usually enough to get the rest of the business to want in. Untangling which of many existing models should become the certified one is fiddly, and it is a common piece of our Microsoft Fabric consulting work, because Fabric's OneLake and the Power BI data hub share the same discovery model underneath.
The whole thing comes back to a simple principle. A number should mean one thing across your business, and it should be defined in one place. Shared semantic models are how you make that true in Power BI. If you would like a hand designing a model layer that stops your dashboards contradicting each other, that is very much what we do, so take a look at our data and analytics services or just get in touch.