Power BI Semantic Model Permissions - Getting Access Right Without Locking Everyone Out
Here is a situation I have walked into more than once. An organisation has invested properly in Power BI, built a clean semantic model that everyone is supposed to build reports from, and then one of two things has happened. Either nobody can access it, so people quietly go off and build their own duplicate models from raw data, which defeats the entire point. Or everyone can access everything, including sensitive HR and finance data that should never have been visible that widely. Both are permission problems, and both are more common than you would hope.
Semantic model permissions are how you control who can do what with your shared datasets in the Power BI service. Get them right and you have a reusable, governed layer that the whole organisation builds on. Get them wrong and you either have a bottleneck or a data leak. Microsoft's documentation on semantic model permissions is the reference. This is the practical view from someone who has had to untangle these on real client tenants.
First, why semantic models matter at all
Quick bit of context, because the permissions only make sense once you get why the shared model exists.
A semantic model, which Power BI used to call a dataset, is the layer that sits between your raw data and your reports. It holds the tables, the relationships, the measures, the business logic. The whole idea of a shared semantic model is that you build that logic once, properly, and then everyone builds their reports on top of it. Sales is defined once. Margin is calculated once. Everyone using the model gets the same numbers because they are all drawing from the same definitions.
This is genuinely one of the best things about Power BI when it is used well, and one of the most ignored. The alternative, where every analyst pulls raw data and reinvents the business logic themselves, is how you end up with six different definitions of revenue and a meeting where nobody's numbers agree. The shared model prevents that. But only if people can actually access it, which brings us to permissions.
The permissions that actually matter
There are a handful of permissions on a semantic model, and the two that do the heavy lifting day to day are Read and Build.
Read lets someone view reports that are built on the model. If a report sits on top of a semantic model, a person needs read access to the model, usually granted implicitly through access to the report or the workspace, to see the report and its data. This is the basic "can this person look at this dashboard" permission.
Build is the more interesting one and the one people get wrong. Build permission lets someone create new content on top of the model. Build their own reports against it, create a paginated report, analyse it in Excel, export the underlying data, or connect to it with a live connection. Build is what turns a semantic model from something you can only look at into something you can actually reuse. If you want your organisation to build on a shared model rather than reinventing it, Build permission is the thing you need to hand out, and it is the thing people forget to hand out.
That is the crux of the "nobody can access it" failure mode. Someone builds a lovely central model, shares the reports so people can view them, but never grants Build. So when an analyst wants to make their own report from that trusted model, they cannot, and rather than raise a ticket and wait, they just pull the raw data and build their own thing. The shared model gets bypassed, and all that careful work is wasted. The intent was there, the Build permission was not.
There is also Reshare and Write in the mix, controlling whether someone can pass access on to others or modify the model itself, but Read and Build are where most of the practical decisions live.
How we set this up for clients
When we design a Power BI governance setup, permissions are not an afterthought bolted on at the end. They are part of the model's design, because who should be able to build on this and who should only view it is a real business question, not a technical detail.
The pattern we lean on most is managing access through workspaces and apps rather than granting permissions on individual models one person at a time. Individual grants do not scale and they become impossible to audit. Six months in, nobody can tell you who has access to what or why. Workspace roles and app audiences, with access driven by security groups, are far more maintainable. You add someone to a group, they get the right access. They leave, you remove them from the group, and their access goes with them. No orphaned permissions sitting around because someone forgot to revoke them.
We also think hard about the Build boundary specifically. Who genuinely needs to create new content on this model, and who only needs to view existing reports? Analysts and power users who build their own reports need Build. The average person who just wants to look at the sales dashboard on a Monday does not, and giving it to them widens your data exposure for no benefit. Getting this line right is most of the job. Too tight and you get the bypass problem. Too loose and you get the exposure problem.
And we pay close attention to sensitive data. If a semantic model contains anything sensitive, salaries, individual customer records, financials that are not for general eyes, then Build permission on that model is a bigger deal than it looks, because Build lets people export and analyse the raw underlying data, not just see a curated report view. A report can show a carefully filtered slice. Build access can go around that and get at everything underneath. That distinction catches people out constantly, and it is exactly the kind of thing our Power BI consultants check when we review a client's setup, because a permission that looks harmless can quietly expose far more than the report in front of it suggests.
Where it gets confusing
Honest assessment, because this area has some genuinely confusing corners.
The relationship between report access and model access trips people up. When a report and its model live in the same workspace, access often flows together and it all feels simple. But the moment you have a report in one workspace built on a model in another, which is a completely normal and recommended pattern for reuse, the permissions become two separate things you have to manage deliberately. People grant access to the report and cannot work out why the user still cannot see the data. The answer is nearly always that they were never given access to the model sitting in the other workspace. Once you understand the split it is obvious. Before that, it is maddening.
Implicit versus explicit permissions add to the fog. Some access is granted implicitly through workspace roles, some explicitly on the model itself, and when someone cannot see something the debugging question of "how did this person get, or not get, access" can take a while to answer. My advice is to standardise on one approach, ideally group-based access through workspaces, so you are not chasing permissions that came from four different directions.
And Build permission is genuinely powerful in a way that is easy to underestimate. It is not just "can make reports." It is "can get at the underlying data, export it, and analyse it however they like." Treat granting Build as a data access decision, because that is what it is, rather than a convenience toggle you flip so someone stops asking you for things. That reframe alone prevents most of the accidental exposure I have seen.
The bigger picture
Permissions on semantic models are a small technical feature that sits on top of a much bigger question: does your organisation treat data as a shared, governed asset, or as a free-for-all? A well-designed permission model is a sign of the former. It says we have thought about who should build on what, we have drawn sensible lines around sensitive data, and we have set it up so it stays manageable as the organisation grows and people come and go.
The organisations that get this right get the full value of Power BI's shared model approach. One trusted definition of the numbers, reused everywhere, with access that matches what people actually need. The organisations that get it wrong end up with either a bottleneck that pushes people back to spreadsheets or a sprawl of duplicate models and quietly over-exposed data. The feature is small. The consequences of getting it wrong are not.
As reporting connects more tightly to AI and natural language tools across the Microsoft stack, this governance matters even more, because those tools inherit the same permission boundaries, and a messy permission model becomes a messy and risky AI surface. Getting the foundations right first pays off twice. If you are thinking about your data platform as something that has to support AI properly and not just dashboards, that is a strategy conversation, and it is the kind of thing our business AI strategy work is built around.
Where I would start
If you have an existing Power BI environment and no clear picture of who can access what, start with an audit of your most sensitive models. Who has Build permission on them, and does every one of those people genuinely need to be able to export the raw data? You will very likely find grants that made sense once and should have been revoked long ago.
If you are setting things up fresh, design the permission model alongside the semantic model, drive access through security groups and workspaces rather than one-off grants, and treat Build permission as the meaningful data access decision it actually is. It costs a little more thought up front and it saves you an ugly retrofit and a nervous audit later.
Semantic model permissions are not glamorous, but they are where the promise of a shared, governed data layer either holds together or quietly falls apart. If you want Power BI set up so people can build on trusted data without your sensitive numbers leaking out the side, that is very much what we do. Have a look at our data and analytics services or get in touch and we will take a look at where you stand.