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.
Roles in the Workspace
Let’s have a look at what are roles and their access levels in a 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.
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.
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.
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.
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;
Another thing that is Member role can do is individual sharing of reports and dashboards in the workspace;
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.
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.
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.
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;