Best Practice for Power BI Workspace Roles Setup

Power BI workspaces are not like the old days when we had Edit access and View access only. You have more options for roles in a workspace, and in my courses, I have found that many people have chosen 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.

Video

Power BI Workspace These Days

There was an old version of Power BI workspace for a while, and still, a few people are using that. Microsoft started migrating all of those workspaces (called workspace version 1) to the new version (workspace version 2), but you may still have some old versions in your environment. In the old workspace version, 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 roles and their access levels are in a workspace.

Viewer

This role is viewing the content of the workspace. This role can view every report, dashboard, and workbook in that workspace.

This user can not use Analyze in Excel option on reports or have a connection to the datasets or dataflow. Unless it is given Build permission.

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

If this role is given a Build permission, then the role can also build content with Analyze in Excel or live connection to the dataset.

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.

Contributor

The contributor role is the role of 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 delete it. They can publish a report into the workspace or remove it. The contributor role allows them 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, etc.

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

Member

The member role is the role that has access to all Contributor role’s actions, plus the ability to Publish an App, 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 role can publish the content of a workspace as an App for the end-users.

The Member role has one of the most important actions in the workspace. The action of pushing the content from the DEV environment to the USER environment.

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

I wrote an article when the new workspace version was announced 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 for a developer from the DEV team mistakenly push the button and publish content that is not yet user-ready to the end users. You can avoid that by separating the people who have access to the Member Role and restricting it only to the group of people who are your deployment managers.

There is, however, a tricky checkbox in the Advanced tab when you create a workspace that gives the Contributor role access to publish an app. I strongly recommend NOT using this option. If you do this, you are making the Contributor and Member the same and go back to the old version of the workspace where there is no control over who publishes the content.

The 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;

Admin

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 and 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 and won’t even be able to use Analyze in Excel.

End-Users

I have seen many organizations 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 in the developer environment. The DEV environment content is likely to change by any 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 reliable content while the developers work on changes behind the scenes.

When you build a Power BI App, you can specify a navigation menu, design a great look and feel for your users, and give them 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 the Viewer role, I vote against it. If I have 15 Power BI reports in the workspace, and out of those, only three are test-ready, then I should only share those three reports. As you have already learned, the Member role can share reports or dashboards individually. Sharing items individually can be a better way for the test user than the Viewer role. You don’t give the user access to the entire DEV content, and the users can only focus on test materials.

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 test users.

Contributor Role: Developers Only

Developers of your team should all have contributor access to the workspace. There is no need to give them the Member role. Reserve the Member role for the next group. The Contributor access will give the developer all the access he or she needs. With the Contributor role, the developer can upload content, update it, change it, delete it, build new objects, etc.

Member Role: Deployment Group Only

In your team, there should be a person or a group of deployment gatekeepers. 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 group’s admin 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. Contributors can edit the content. If you think about these actions, there is little need for a person or a group of people to be admin. So only give 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 security is never to use individual accounts. In the Power BI world, there are some places where you can, and somewheres you cannot use security groups instead of individual accounts. Everywhere 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.

Summary

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

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 12 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, Power BI Summit, and Data Insight Summit.
Reza is author of more than 14 books on Microsoft Business Intelligence, most of these books are published under Power BI category. Among these are books such as Power BI DAX Simplified, Pro Power BI Architecture, Power BI from Rookie to Rock Star, Power Query books series, Row-Level Security in Power BI and etc.
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.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog: https://radacad.com/blog.