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.