Build Permission in Power BI - The Setting That Quietly Decides Who Can Do What

Of all the permissions in Power BI, Build is the one that causes the most confusion per line of documentation. It sits quietly behind shared semantic models, and it's the difference between a colleague being able to build their own report on your data and getting a cryptic error that sends them straight to the service desk. Nobody notices it until it's wrong, and then everybody notices it at once.

I've watched Build permission derail more than one Power BI rollout, not because it's complicated, but because it's invisible until it bites. So let me lay out what it actually controls, why it exists, and how to grant it in a way that doesn't generate a steady drip of confused users. Microsoft's official documentation has the reference; this is the field guide.

What Build permission actually gates

Start with the distinction that clears up ninety per cent of the confusion. There are two fundamentally different things a person might want to do with a semantic model:

Consume a report someone already built. Look at it, click the slicers, read the numbers.

Build something new on the model's data. Create a report, export the underlying data, connect to it from Excel with Analyze in Excel, pin a live tile, or query it via the XMLA endpoint.

Read access covers the first. Build permission covers the second. That's the whole idea. Someone can be given a report to view without ever being allowed to get at the raw data underneath it, which is exactly what you want when the model contains something sensitive and the report is a curated, safe view of it.

So Build permission is really "can this person get at the data itself, not just the picture I painted with it." Once you frame it that way, the security logic makes sense. You hand out reports freely; you hand out Build deliberately.

The four ways someone ends up with Build

This is where people trip, because Build can arrive through several doors and users rarely know which one let them in.

Granted directly on the model. You share the semantic model and tick Build permission, or grant it through the model's manage-permissions screen. Explicit and clean.

Through an app. When you publish an app and include Build in what the audience receives, everyone in that audience gets Build on the underlying models. Handy for distributing to a wide group, easy to forget you did it.

Through a workspace role. Members, contributors, and admins of the workspace holding the model get Build implicitly. This is the one that surprises people. Add someone to a workspace so they can help with one report, and you've also given them Build on every model in it.

Through the tenant. Nothing arrives here automatically, but tenant admin settings govern whether these grants are even allowed, and a switch flipped the wrong way can quietly block the whole pattern.

The practical problem is that with four routes in, working out why a specific person does or doesn't have Build turns into detective work. I've spent more time than I'd like reverse-engineering someone's effective permissions across a workspace role, an app audience, and a direct grant that contradicted each other. It's tedious, and it's avoidable with a bit of discipline up front.

Why this generates so many support tickets

Here's the exact scenario that plays out in nearly every organisation running shared models. A report gets shared widely. Someone opens it, finds it useful, and thinks "I want a version of this with my own tweaks." They hit Save As, or try to create a new report on the same data, and Power BI stops them with a permission error because they have read access but not Build.

From the user's side this is baffling. They can see the data, the numbers are right there on screen, why can't they build on it? The distinction between viewing a report and accessing its model is not intuitive to a business user, and the error message doesn't explain it. So they raise a ticket, and someone on your side has to explain the read-versus-Build distinction for the fortieth time.

The fix is not technical, it's anticipatory. Decide up front who's allowed to grant Build and how people request it. Write the two-line explanation of read versus Build before the tickets start, not after. When we set this up for clients as part of Power BI consulting work, half the value is just having answered these questions before the rollout rather than during the pain. The mechanics take an afternoon; the confusion, left unmanaged, takes months.

How to grant it without losing control

The pattern that holds up over time is straightforward, and it's the same discipline that makes any permission system survivable.

Grant through security groups, not individuals. A group called something like "Sales Model - Report Builders" is auditable, survives staff turnover, and means you're managing membership in one place rather than chasing individual grants across dozens of models. Individual grants rot the moment someone changes roles, and nobody ever goes back to clean them up.

Be deliberate about workspace membership. Remember that adding someone as a workspace member hands them Build on everything in that workspace. If your shared models live in a dedicated data-team workspace, keep membership of that workspace tight and let report authors get Build through explicit grants or app audiences instead. This is a strong argument for the separated-workspace pattern where models and reports live apart, which we covered in running semantic models across workspaces.

Treat Build as access to data, and govern it that way. Because Build lets someone export and query the raw model, it should be governed with the same care as any data-access decision. If the model has row-level security, understand how it interacts, RLS still applies, but Build widens the surface of how people can pull the data out. For anything sensitive, the question "who has Build on this model" should have a clear, current answer, not a shrug.

Audit it periodically. Build grants accumulate. Apps get published with Build included and forgotten. People get added to workspaces for a one-off task and never removed. Every so often, someone should look at who has Build on the models that matter and confirm it still makes sense. Nobody enjoys this job, which is precisely why it needs to be scheduled rather than left to good intentions.

Where it connects to the bigger picture

Build permission looks like a small technical setting, and in isolation it is. But it sits at the exact point where governance meets self-service, which is the tension every Power BI estate eventually has to resolve. Grant Build too freely and you've got sensitive data flowing out through Analyze in Excel with no oversight. Grant it too tightly and you've killed the self-service reporting that was the whole reason you bought the platform. The right setting is a judgement call about your organisation's appetite, not a default you can copy from a blog post.

That judgement gets sharper the moment AI enters the picture. When agents and natural-language tools start reading from your semantic models, "who can access this data" stops being purely about human report authors and starts including what your AI layer can reach on someone's behalf. The permission model you build now for reports is the foundation the AI access model inherits, and getting it coherent early saves a genuinely awkward retrofit later. That intersection of data access, governance, and AI is most of what our AI for business intelligence engagements end up untangling.

The short version

Build permission controls whether someone can create their own reports and get at the raw data of a shared semantic model, as opposed to just viewing reports built on it. It arrives through four different doors, which makes it confusing to trace. It generates predictable support tickets when users hit the read-versus-Build wall. And it's best managed through security groups, tight workspace membership, and a periodic audit that nobody wants to do.

Get it right and self-service reporting flows without anyone thinking about it. Get it wrong and you either leak data or throttle your own users. If you're standing up shared models and want the permission model designed properly the first time rather than patched after the tickets start, that's a conversation worth having early, so get in touch and we'll help you draw the lines.