How Do You Manage Permissions in Power BI?

How Do You Manage Permissions in Power BI?

Power BI has no single permissions screen. Access is assembled from several layers that were added at different times, and they do not all behave the same way.

Most teams discover this the moment someone sees a number they should not have seen. The report had row-level security on it. The security was fine. The role was wrong.

That failure is not a bug, it is documented behaviour, and it is the single most useful thing to understand before you hand anyone access.

What Is the Short Answer?

Permissions in Power BI are granted in three places, and you should pick the narrowest one that does the job.

Workspace roles decide who can build. Item sharing decides who can see one specific report. App audiences decide what a group of readers is shown.

There are four workspace roles: Admin, Member, Contributor and Viewer. Microsoft documents them in that order of decreasing power.

The rule most people need is simpler than the matrix suggests. If someone only consumes reports, they belong in an app audience or a Viewer role, never in Contributor.

Not sure who can currently see your reporting, or what the data behind it is actually telling you? Get a free SEO audit and start from an accurate picture.

What Does Each Workspace Role Actually Do?

A workspace role is a blunt instrument. It applies to everything in the workspace at once, and there is no way to grant it over a single item.

Admin

Admin is the only role that can delete the workspace. It is also the only one that can fully manage who else is in it.

Microsoft's capability list gives Admin "Add or remove any user in a workspace role" and, in the Fabric wording, "Add or remove people, including other admins."

Admin also owns a few things no other role touches, including managing subscriptions other people created and connecting the workspace to a Git repository.

Member

Member looks almost identical to Admin until you try to use it for access management, and then it is not.

Members can publish, unpublish and change permissions for an app. They can also add people, but only downward: "Add members or others with lower permissions."

Here is the gotcha, in Microsoft's own words: "Members can add users to a workspace with lower permissions, but can't remove users from any workspace roles."

So a Member can let someone in and then cannot let them out. If you are delegating access management, Member is not the role that does it.

Contributor

Contributor is the build role. It can create, edit and delete content in the workspace, copy reports, schedule gateway refreshes and download the .pbix file.

What it cannot do is publish a new app or change who may edit one. It can only update an existing app, and only if an Admin has switched that on.

Contributor is where most accidental over-granting happens, because it reads like a modest role and is in fact a data-access role. More on that below.

Viewer

Viewer can view and interact with items and read data stored in workspace dataflows. That is close to the whole list.

Two documented exceptions are worth knowing. Analyze in Excel requires Build permission on the semantic model, and Microsoft notes that "Viewer permissions isn't sufficient and isn't supported for consuming data from the dataflow gen2."

How Do You Assign Permissions, Step by Step?

1. Decide the layer first. If the person is reading, not building, stop before you reach the workspace. Publish an app or share the single item instead.
2. Assign roles to groups, not people. Microsoft supports "security groups, Microsoft 365 groups, and distribution lists" for workspace roles, and recommends groups explicitly for app access.
3. Know how overlapping groups resolve. The documentation is unambiguous: "If someone is in several user groups, they get the highest level of permission that's provided by the roles that they're assigned."
4. Set up row-level security in Desktop. RLS roles are defined under the Modeling tab, then Manage Roles. You cannot assign users there.
5. Assign RLS members in the service. Open the semantic model's Security option. Microsoft notes that "Users with the workspace Contributor role or higher see the Security option and can assign users to a role."
6. Test the role before you distribute. Use More options next to the role, then Test as role, which does not work for DirectQuery models with single sign-on enabled.
7. Publish an app for readers. From the workspace list view, select Create app, then work through Setup, Content and Audience, then Publish app.
8. Create a separate audience per group of readers. Each audience sees only what you put in it, which is how one workspace serves several teams.

When Should You Use Sharing Instead of a Workspace Role?

Microsoft's framing is useful here: "Sharing is a good way to give a few people access to your reports and dashboards."

That is the whole decision. Sharing is for a handful of named people. Apps are for distribution at scale. Workspace roles are for the people building the thing.

Sharing one report also comes with a caveat people hit in practice: "You cannot share reports that are distributed to you in an app."

And the thing being shared is bigger than it appears: "When you share a semantic model by managing permissions, by sharing reports or dashboards, or by publishing an app, you are granting access to the entire semantic model unless row-level security (RLS) limits access."

Want an independent read on the data your reports are built on before you widen access to them? Request a free audit.

What Are the Limits Worth Knowing Before You Design This?

App distribution has hard numbers. You can create one app per workspace and up to 25 audience groups in that app.

Access caps out too. "A total of 10,000 users and user groups combined can have access to an app," with each group counting as one entry against that total.

Per audience the limit is lower: you can add up to 1,000 users or user groups per audience group, and workspace users are counted again in every audience.

Updating an app does not claw anything back. Microsoft states that if you removed permissions as part of an update, "the update won't remove the permissions from users who already have them."

Two more limits catch people out. A Pro licence holder can belong to a maximum of 1,000 workspaces, and apps can hold a maximum of 200 dashboards.

Gateway permissions sit outside all of this. The documentation is explicit that those "permissions are managed elsewhere, independent of workspace roles and permissions."

So does offboarding. "Disabling a user in Microsoft Entra ID doesn't remove the access records for Power BI workspaces or other items the user was granted access to."

Why Does Row-Level Security Not Apply to Everyone?

This is the part that surprises people, and it is stated plainly rather than buried.

Microsoft's RLS documentation says: "RLS only restricts data access for users with Viewer permissions. It doesn't apply to workspace Admin, Member, or Contributor roles."

Read that against the roles above and the consequence is immediate. Putting an analyst in Contributor so they can tidy up a report also exempts them from every RLS filter in the workspace.

Build permission does not change it in the other direction either: "Even if Viewers are given Build permissions to the semantic model, RLS still applies."

RLS is also additive rather than restrictive across roles, since "A user can belong to multiple roles, and the roles are additive." More roles means more rows, not fewer.

And it does not filter columns at all. Microsoft answers that directly: "if a user has access to a particular row of data, they can see all the columns of data for that row."

The Group Type That Works Everywhere Except RLS

Here is a genuine contradiction between two of Microsoft's own pages, and it is worth planning around rather than discovering.

The workspace role pages support Microsoft 365 groups. The RLS page does not: "Microsoft 365 groups aren't supported and can't be added to any RLS roles."

RLS accepts a distribution group, a mail-enabled group or a Microsoft Entra security group. So the convenient group type at the workspace layer is the one that cannot carry security at the data layer.

If RLS is anywhere in your plan, standardise on Entra security groups from the start. Converting later means re-doing both layers.

Two related notes. Service principals "can't be added to an RLS role", and Microsoft states that "Power BI doesn't sync Microsoft 365 group membership with workspace permissions."

How Does This Compare to the Alternatives?

Against tenant-level administration, workspace permissions are a different job entirely. The admin portal governs settings across the organisation; it does not decide who opens one report.

Against item sharing, workspace roles are heavier and blunter. Sharing is the right tool when the audience is three people and the content is one report.

Against apps, workspace roles are the wrong tool for readers. An app with audiences gives you segmented distribution without putting a single consumer into a build role.

Against RLS, workspace roles are not a substitute. RLS filters rows within a model; roles decide whether that filtering runs at all. You normally need both.

One thing Microsoft does not settle cleanly is licensing at the sharing layer. The apps page extends the free-viewing exception to "Power BI Premium capacity or Fabric F64 or higher capacity."

The sharing page says only that "you and your recipients need a Power BI Pro license, or the content needs to be in a Premium capacity." It does not mention Fabric capacity at all.

Microsoft does not publish, on either page, whether the F64 exception covers individually shared reports. Treat that as unconfirmed rather than assuming it carries over.

Resharing is inconsistent across the same two pages as well. One conditions it on an app setting, the other on holding Reshare permissions, and the conditions are not the same.

Planning a permissions model and want to make sure the reporting behind it is sound? Start with a free audit.

Final Thoughts

Power BI permissions are not complicated so much as layered, and the layers were not designed together. Most mistakes come from using the wrong layer rather than the wrong setting.

The practical sequence is short. Readers get an app audience. A named few get item sharing. Builders get a workspace role, and only builders.

Then check the role you gave your builders against your RLS, because Contributor and above are documented as exempt from it. That one check prevents the failure nobody notices until it matters.

Finally, assign roles to Entra security groups rather than to individuals, which keeps RLS usable and makes offboarding a group-membership change instead of an audit.

If you are working at the tenant level rather than the workspace level, the companion piece is our guide to how to access the Power BI admin portal, which covers the settings that sit above everything here.

Want to see whether your reporting is built on data worth protecting this carefully? Get a free SEO audit.