Assigning Workspace Roles
Start course

This course is designed to lead users through the experience of working with Power BI content in the Power BI service. This web-enabled environment is where content creators and business users go to develop, deploy, and consume content. This course will walk through the process of creating Power BI workspaces in this environment, provisioning user roles, and publishing content to these spaces. It will also walk through the steps necessary to make that content available to a larger business audience by developing workspace apps.

Content in Power BI is also constantly iterated upon, and this course will establish best practices for development lifecycle strategy and the use of premium features like deployment pipelines. Once Power BI content is deployed, it must also be accessible and discoverable. This course will examine processes for promoting and certifying Power BI content and configuring subscriptions so that content can be emailed to users at a defined frequency.

Learning Objectives

  • Create a Power BI workspace
  • Assign workspace roles
  • Publish a Power BI desktop file
  • Create a workspace app
  • Create a dashboard in a workspace
  • Certify a dataset
  • Configure a subscription

Intended Audience

This course is designed for individuals who are working with Power BI and those studying for Microsoft’s Power BI Certification assessment.


To get the most from this course, you should have reasonable experience working with Power BI. If you're new to Power BI, we recommend taking our Introduction to Power BI course.


Once a workspace has been set up in the Power BI portal we need to consider how we will allow others to access this environment. This is done by assigning workspace roles. The purpose of workspace roles is to provide a tool for teams to collaborate on content in Power BI. Once a user is given any workspace role that workspace appears in their individual Power BI portal. Each of the four roles available provides a different level of control that can be taken on content in a workspace and also impacts additional actions a user can take inside the workspace.

One example we will revisit later is how workspace roles can impact features like row-level security. There are four distinct roles a user can have in a given workspace. In order of capability, they are admin, member, contributor, and viewer. These are selected from the workspace access menu and assigned to users by entering their email address or a security group that they belong to. The creator of the workspace is automatically assigned an admin role.

Here's a summary of all the features available to users in a workspace. As we can see, the list is quite extensive. And each type of user is provided with some capabilities. Let's take a closer look at what sets each user group apart from each other. Workspace admins have the highest role available and as such can take any and all actions available to them. The actions unique to admins are that they can add and remove other workspace admins. They can also update or delete the workspace and give permissions to contributors to update a workspace app.

Importantly, workspace admins are not subject to any row-level security that has been applied to a dataset in that workspace. Workspace members have nearly the same controls as admins, but can only add and remove other members and cannot delete the workspace. They're able to update features involving a workspace app and dataset permissions that might have been set. Members can also share items. Similar to admins, members are not impacted by any row-level security set on a dataset.

Contributors can create, edit, and delete content in a workspace, including publishing reports. They can also copy content, create goals, and schedule data refreshes. Similarly, those in a contributor role will not be impacted by row-level security either. Workspace viewers have the lowest and most limited abilities. They can only see the workspace and interact with reports. They do not see datasets and are the only users impacted by row-level security. This role is likely only useful for a small group of users that test the delivery of a report and ensure that features like row-level security are working as expected.

Another consideration for workspace access is whether or not to enable a premium or premium per user capacity. This can be toggled on or off after a workspace has been created. These are separate considerations than workspace roles, but can impact whether a user has access. For example, only users with premium per user licenses can interact with content in a premium per user workspace, regardless of what role they are provisioned.

One lingering question might be, who should be invited to the workspace in the first place? We should consider workspaces to be development environments only. This means that only those assisting with the report development effort should be invited. Business users not involved in this effort should not be invited. They should consume Power BI content from a workspace app and not by invitation to the workspace directly. We'll cover this in a later topic.

About the Author

Steve is an experienced Solutions Architect with over 10 years of experience serving customers in the data and data engineering space. He has a proven track record of delivering solutions across a broad range of business areas that increase overall satisfaction and retention. He has worked across many industries, both public and private, and found many ways to drive the use of data and business intelligence tools to achieve business objectives. He is a persuasive communicator, presenter, and quite effective at building productive working relationships across all levels in the organization based on collegiality, transparency, and trust.