What are the Workspace Access Roles in Power BI?

Shared workspaces are essentially collaborative containers in Power BI Service where developers can create and edit content collectively; the type of content that can be stored in a workspace includes reports, dashboards, datasets, and dataflows. 

Whether your organization needs to restrict access to a subset of sensitive data, or your developers are the only ones that need access to pre-production workspaces, understanding the different permissions that are available in Power BI Service is critical to both performance and security.

In this blog, we’ll cover the four levels of access that Power BI has, the difference in permissions between them, and where to go in your workspace to assign users those roles.

What are Workspace Access Roles?

Workspace access roles allow organizations to grant different permissions to users depending on their level of involvement in either the development or administration of content. There are four roles that users can be assigned to (view chart at the bottom of this blog post for the full list of details).

Admin:

  • View content in and delete a workspace.
  • Create, edit, delete, copy and publish content in a workspace.
  • Publish, update, or share a workspace app.
  • Configure and modify data refresh schedules and gateways.
  • Add or remove other users, including other admins.

Member:

  • Can do everything an admin can do except add or remove users, or delete the workspace.
  • Can add other users to the viewer or contributor roles.

Contributor:

  • Can create, edit, delete, copy and publish content within a workspace.
  • Cannot publish, update, or edit a workspace app unless given the ability to by workspace admins or members.
  • Can modify data refresh schedules and gateways.
  • Cannot add or remove users.

Viewer:

  • Can only view a report or dashboard in a workspace.
  • Cannot add or remove users to a workspace.
  • Can read data that is stored in workspace dataflows.

Why are Access Roles in Power BI Important?

The importance of this topic all comes down to data security. It’s considered best practice not to give every user the same permissions to workspace content. This is best explained with an example. 

Let’s say your organization has a workspace that contains datasets and reports. The datasets store the logic used to calculate the KPIs necessary for tracking the health of your business in the reports. All of the calculations are written and tested by members of the development team. 

You would not want an analyst whose job it is to track the KPIs in the report to accidentally edit, overwrite, or delete the dataset that feeds their report. Therefore, the development team would need a different set of permissions than someone who just needs to view the data at the report level.

If your organization has multiple workspaces that are associated with the different stages of lifecycle development (development, test, and production), check out this blog post about how to leverage Power BI Deployment Pipelines to automate the promotion of content between those stages. 

How to Provision Power BI Workspace Access

The easiest way to grant workspace permission to users is from the workspace itself. Use the Access button on the top right of the page, select the permission level from the dropdown menu, and enter one or multiple user emails that you would like to assign to that role (see video below).

a gif demonstrating how to grant access to a Power BI workspace

Full Access Role Details

The chart below is the breakdown of the different permissions granted with each access role.

¹Contributors can update the workspace app, if the workspace Admin gives them permission to do so.

²Contributors and Viewers can also share items in a workspace if they have Reshare permissions.

³Users need Build permissions for the dataset to copy a report to another workspace and create a report in another workspace based on a dataset in this workspace. If a user has at least the Contributor role in the original workspace, they automatically have Build permissions in the new workspace.

⁴Gateways need their own permissions, which are managed independently of workspace permissions.

⁵Even if users don’t have a Power BI Pro license, they can view and interact with content in Power BI Service if the items are in a workspace with Premium Capacity.

Other Methods of Providing Access

If there are a large number of users that need access to the workspace, consider provisioning access by one of the following methods:

  • Use an Outlook email distribution.
  • Use an Azure Active Directory.

Note that if one of the two methods above is used, everyone in the same distribution list or Azure Active Directory will be given the same permissions; thus, you may want to consider creating one group for each access role.

Closing

Organizations should not let their data, or any of the content in their Power BI workspace(s), for that matter, be a free for all. Granting the correct level of permissions to the right organizational roles is necessary for keeping your data and the content in your Power BI environment safe.

Have more Power BI questions? Our team of Power BI experts is here to help!

FAQs

Yes, users can be given access to a workplaces app without having the ability to view or edit any of the content in the workplace. This is done by updating the app, navigating to the Permissions page, and granting access in the same way as a workplace.

No, row level security restricts access to specific rows in a database table based on certain criteria. Workspace permissions grants access to everything in a workspace. Learn more about row level security here.

Yes, sending a link to a report via the Share button will give those included in the email View level permissions.

More to explore

Accelerate and automate your data projects with the phData Toolkit

Introducing
Data Coach is our premium analytics training program with one-on-one coaching from renowned experts.

Data Coach is our premium analytics training program with one-on-one coaching from renowned experts.