Best Practice for Power BI Workspace Roles Setup

Power BI workspaces are not like old days, that we had Edit access and View access anymore. You have more options for roles in a workspace, and in my courses, I have found that many people choose the incorrect role without knowing what the role does. In this article, I’ll explain all the roles in the workspace, and what is the best way to set them up to have a secure workspace.

Power BI Workspace These Days

There were an old version of Power BI workspace for a while, which still a few people are using that. and Microsoft recently explained a method in which you can upgrade your workspace experience from the old version to the new version. In the old version of the workspace, we had Edit access, View access, and Admin access. which is easy to understand. in the new workspace we have four roles.

Assigning roles in a Power BI workspace

Roles in the Workspace

Let’s have a look at what are roles and their access levels in a workspace.

Roles in the workspace


This role is viewing the content of the workspace. This role has access to view EVERY report and dashboard and workbook in that workspace.

This use won’t be able to use Analyze in Excel option on reports, and won’t be able to access datasets or dataflows.

Viewer Role

So, this role, does what it says in terms of viewer access. It only authorizes the user to view the content of the report, dashboards, and workbooks. View role is the read-only access to the content. This use cannot access dataflows, but can access the data stored in the dataflow.

This is a role that, however, I am not a big fan of, I’ll let you know why later. There is a better replacement option for people with this role.


The contributor role is the role for developers in the workspace. These are people who can access not only reports, and dashboards, but also datasets and dataflows. They can Edit the content as well as deleting it. They can publish a report into the workspace, or remove it. The contributor role gives them access to do all their development work in the workspace.

Contributor Role

The Contributor role is the ideal role for Power BI developers. They would be able to do all these actions:

  • Publish a report into the workspace
  • Edit the content in the workspace
  • Delete the content in the workspace
  • access to all workspace objects: reports, dashboard, workbook, dataset, and dataflow
  • Copy content, use Analyze in Excel and etc.

This role, should be assigned to all developers in the team. However, this role should not be confused with the next role: Member Role.


The member role is the role that has access to all Contributor role’s actions, plus the ability to Publish an App, or Unpublish it, or Update the App. The Member role has the worst name across all other roles. And that is one of the reasons why many people don’t understand it.

Consider this role as the Deployment Role. This is the role that can publish the content of a workspace as an App for the end-users.

Member Role

The member role is having one of the most important actions in the workspace. The action of pushing the content from DEV environment to USER environment.

I have seen a lot of workspaces, in which all the developers had the Member access. The big problem with that level of access is what we had as a big issue with the old version of the workspace. Any developer can publish the app to the end-user.

Member Role Vs. Contributor Role

I have written an article more than a year ago and explained that the separation of Member Role and Contributor Role is one of the best advantages of the new version of workspace vs the old version.

The last thing you want is a developer from the DEV team mistakenly push the button and publish the content which is not yet user-ready to the end users. You can avoid that with separating the people who have access to the Member Role, and restrict it only to the group of people who are your deployment managers.

Member role also can set the access for Member-level roles or underneath (contributor, or viewer) in the workspace;

Access Levels from the Member Role

Another thing that is Member role can do is individual sharing of reports and dashboards in the workspace;

Sharing content individually


The admin role has full access to the workspace. In addition to doing all the Member’s role actions, the Admin can add or remove more Admins to the workspace, can update or delete the workspace.

Admin Role

Now that you know about all roles, in the workspace, let me explain how to use them the best.

Viewer Role: Use Power BI Apps Instead

When you think about the View role in the workspace; it is read-only access to all content in the workspace, and won’t even be able to use Analyze in Excel.


I have seen many organizations are using the Viewer roles to give access to their end-users. This is a big mistake, because if you give the end-users the Viewer access to the workspace, then you are giving them access to the content int he developer environment. The DEV environment content is very likely to change by any of the development team members.

Instead use Power BI Apps, which creates a good separation between the DEV and USER environment. In that environment, users can use the reliable content, while the developers are working on changes behind the scene. I have written an article about how Power BI Apps works for that purpose.

Publish App

When you build a Power BI App, you can specify a navigation menu, design a great look and feel for your users, and you can also give the user the ability to slice and dice the data as they wish. This is much better than the View access on the workspace.

Test Users

Some organizations give the Viewer access to test users. That way, the user can test the content before sending it to the end users using the Power BI App.

Although, this seems to be a good use for Viewer role, I vote against it. If I have 15 Power BI reports in the workspace, and out of those only three of them are test-ready, then I should only share those three reports. As you already learned the Member role, can share reports or dashboards individually. Sharing items individually can be better way for the test user than the Viewer role. You don’t give the user the access to the entire DEV content, and user can focus on test materials only.

Some other organizations prefer to have a DEV workspace, and a Test workspace, if that is the case, then the Publish Power BI App can be used even for the test users.

Contributor Role: Developers Only

Developers of your team they should all have the contributor access to the workspace. No need to give them the Member role. Reserve the Member role for the next group.

Member Role: Deployment Group Only

In your team, there should be a person or a group of people who are deployment gate keepers. This group of people would make sure the right content reaches the audience. They will go through a process of some checks in the checklist to make sure the content is ready to publish to users. These are the people who should have access to the Member role. They can then publish this content to the end users.

Admin Role: Admin Group

Don’t make people the admin of the group, because you want to give them a lot of access. Remember that even the Member role can give access to other Member-level or underneath roles. Can deploy etc. Contributor can edit the content. If you think about these actions, there is a little need for a person or a group of people to be admin. So only give the access to the group who want to control the creation or deletion of the workspace, or admin-level access.

Use Groups, Not Individual Accounts

The golden rule in all things about security is to never use individual accounts. In the Power BI world, there are some places that you can and some places that you cannot use security groups instead of individual accounts. Everywhere that you can use a security group, make sure to use that instead of an individual account. Doing it this way will make the control of access even easier, with just adding or removing people from that security group.


In Summary, roles are not split into just View and Edit. There are more in their separation, the below is my recommendation;

Roles Recommendation


Reza Rad on FacebookReza Rad on LinkedinReza Rad on TwitterReza Rad on Youtube
Reza Rad
Trainer, Consultant, Mentor
Reza Rad is a Microsoft Regional Director, an Author, Trainer, Speaker and Consultant. He has a BSc in Computer engineering; he has more than 20 years’ experience in data analysis, BI, databases, programming, and development mostly on Microsoft technologies. He is a Microsoft Data Platform MVP for nine continuous years (from 2011 till now) for his dedication in Microsoft BI. Reza is an active blogger and co-founder of RADACAD. Reza is also co-founder and co-organizer of Difinity conference in New Zealand.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog:
He wrote some books on MS SQL BI and also is writing some others, He was also an active member on online technical forums such as MSDN and Experts-Exchange, and was a moderator of MSDN SQL Server forums, and is an MCP, MCSE, and MCITP of BI. He is the leader of the New Zealand Business Intelligence users group. He is also the author of very popular book Power BI from Rookie to Rock Star, which is free with more than 1700 pages of content and the Power BI Pro Architecture published by Apress.
He is an International Speaker in Microsoft Ignite, Microsoft Business Applications Summit, Data Insight Summit, PASS Summit, SQL Saturday and SQL user groups. And He is a Microsoft Certified Trainer.
Reza’s passion is to help you find the best data solution, he is Data enthusiast.

8 thoughts on “Best Practice for Power BI Workspace Roles Setup

  • With the upcoming release of deployment pipeline feature, will this alter your best practice recommendation? Seems having separate Dev/Test/Prod workspaces will become the new standard?

    • Hi Jerry
      Having separate Dev/Test/Prod workspaces won’t be against what I explained here. Still in that environment, you need to create Apps for the users of each environment, don’t use View roles, give the contributor access to developers of that environment, and Member to deployment manager.

  • Thanks for that great overview, Reza! 🙂
    One question from my side: Is it possible that Contributor can assign Viewers to row level security groups?

    • The contributor cannot set access in the workspace.
      However, the contributor can add users to a role in RLS, that, however, doesn’t mean that the user gets access to the report, because the report still has to be shared with him/her

  • Many thanks Reza for this insight. Is it possible to prevent power bi pro users from creating workspaces and leave the creation to a power bi Premium admin ?

  • Hello Reza, Thank you for explaining the different workspace roles. My understanding is that a user with a member role can change the roles for other users with less or equal roles. But, I have a user with a member role that can’t even see the ellipses to change to the roles for other users. Not sure what else to look at?

Leave a Reply

%d bloggers like this: