Sharing Semantic Model Access in Power BI - Getting the Preview Feature Right

The single biggest improvement most Australian businesses could make to their Power BI setup has nothing to do with better charts or fancier DAX. It's this: stop building the same data model forty times. Have a few well-built, trusted semantic models, and let everyone build their reports on top of those instead of importing their own copy of the data every time. One definition of revenue. One customer table. One version of the truth.

The catch has always been access. To build a report on someone else's semantic model, you need permission to use that model, and Power BI's permission story around this has been fiddlier than it should be. The share semantic model access feature, currently in preview, is Microsoft tidying that up - giving you a cleaner way to grant a person access to a model so they can connect to it and build on it. If you're serious about the shared-model pattern, this is the plumbing that makes it practical.

The problem it's solving

Picture the good version of Power BI in an organisation. A data team builds a certified "Sales" semantic model - clean, well-tested, with agreed measures. Analysts across the business build their own reports on top of it. The finance analyst builds their view, the regional managers build theirs, marketing builds a campaign dashboard. They all share the same underlying model, so when someone asks "what was revenue last month", every report gives the same answer. Change the revenue logic once, in the model, and every report updates.

For that to work, all those report builders need permission to connect to the model. Historically this meant either putting everyone in the model's workspace, which gives them far more power than "let me build a report" needs, or fighting with build permissions and app audiences. Plenty of shared-model rollouts quietly died right here, because getting people access was annoying enough that they gave up and just imported their own copy of the data instead. And once someone imports their own copy, the whole one-version-of-the-truth story is gone.

Sharing semantic model access is meant to make the grant clean: give this person the ability to discover and build on this model, without handing them the keys to the workspace. That's the right shape. Access to build on a model should be a small, specific permission, not workspace membership.

What the feature gives you

At its core it lets a model owner share a semantic model with specific people and set what they can do with it - read it, build new content on it, and reshare it onward. The build permission is the important one for the shared-model pattern. Build is what lets someone create a new report or a connected Excel workbook against your model. Without it, they can maybe view existing reports but can't create their own, which defeats the purpose.

The discovery angle matters too. A big part of making shared models work is that people can find the models they're allowed to use. A model nobody can discover is a model nobody builds on, and you're back to everyone rolling their own. Cleaner sharing plus the endorsement features - promoting and certifying models so they surface as the trusted option - is how you steer an organisation towards the good models instead of leaving people to guess.

This is the exact structure our Power BI consultants put in place when a client wants to move from spreadsheet chaos to a governed BI setup: a small number of certified models, thin reports built on top, and access granted at the model level so the whole thing scales without the workspace becoming a free-for-all.

The honest caution - it's preview, and permissions sprawl is real

Two things to keep front of mind.

First, this is a preview feature. That means the behaviour and the interface can change, and I wouldn't build a rigid, documented organisation-wide process around it and assume every detail stays put. For piloting the shared-model pattern with a willing team, preview is fine. For a locked-down enterprise governance standard that has to survive an audit, I'd be more cautious and keep an eye on when it goes to general availability. Test how it behaves in your tenant rather than trusting that it works exactly as you expect - preview features occasionally have rough edges around how they interact with existing app permissions and workspace roles.

Second, and this is the one that bites everyone eventually: direct sharing scales badly if you do it person by person. Grant access to individuals one at a time and in eighteen months you have a semantic model shared with forty-three named people, nobody remembers why half of them have access, three have left the company, and unpicking it is a genuine chore. Direct per-person sharing is convenient today and a mess later. The habit worth building from day one is to share with security groups, not individuals. Grant "Sales Analysts" build access to the Sales model once, and manage membership of that group where you manage all your other access. When someone joins the team they get the group and the access comes with it. When they leave, removing them from the group removes their access everywhere. This is basic access hygiene and it's the difference between a setup you can reason about and one you're afraid to touch.

Watch the reshare permission specifically. Letting people reshare a model onward is handy right up until you've lost track of who actually has access because it spread sideways through resharing. For anything sensitive, I keep resharing off and route access requests back through the group. It's slightly less convenient and dramatically easier to govern.

How I'd roll this out

Start with the models, not the sharing. There's no point cleanly sharing access to a model that isn't worth building on. Get one or two genuinely good, certified models in place first - correct measures, tested, endorsed - then use access sharing to open them up. Sharing access to forty mediocre models just distributes the mess more efficiently.

Decide your access model up front. For each shared semantic model, define who should be able to build on it, and express that as a security group. Write down the rule. "Anyone in the Finance Analysts group can build on the Finance model" is a policy you can maintain. "We add people when they ask" is not a policy, it's how you end up with forty-three names and no memory of why.

Pair it with row-level security where the data needs it. Giving someone build access to a model means they can query it. If different people should see different slices of the data - regional managers seeing only their region, say - that's row-level security in the model doing the work, and it needs to be right before you open the model up widely. Build access plus proper RLS is a powerful combination. Build access without RLS on data that needs it is a leak waiting to happen.

The bigger picture here is that Power BI rewards organisations that treat their semantic models as shared products and punishes ones that treat every report as an island. Cleaner access sharing removes one of the last friction points in doing it the right way. It's genuinely good news, preview status and all. Getting the model quality, the access strategy and the security right together is where the real work is, and it's exactly the sort of thing we help with through our business intelligence practice. If your tenant has quietly grown into dozens of duplicated models and you'd like to consolidate onto a handful of trusted ones, come and talk to us - it's satisfying work and the payoff is a business that finally trusts its own numbers.