After Power BI Workspace setup – part 1, which was mainly about creating your workspace, giving it the right name etcetera, this blog will elaborate on workspace permissions. If you did not read part 1 yet, I encourage you to start at that blog to get the basic setup in place.

You might think, permissions is an easy topic, but often underestimated! In this blog I will describe the different workspace roles, and how you can apply them in your project. Also we will look at sharing specific content from a workspace perspective, such as sharing dataflows.

Existing Workspace permission levels

In Power BI, there are two types for workspaces. Classic and modern workspaces. Classic workspaces are actually Microsoft 365 groups and share a bunch of additional Microsoft services such as SharePoint, Teams and more! You might wonder why I’m starting here. Well, classic workspaces have different permissions levels than modern workspaces. As classic workspaces will be deprecated, I highly encourage you to upgrade your workspace to a modern type of workspace!

In case you own one of those classic workspaces, you can learn more about the upgrading process and exact differences between both types of workspaces in this documentation. Are you a Power BI Service Administrator? In that case you can bulk-upgrade your organizations classic workspaces to modern via the admin portal as described here.

In the remaining of this blog, I will assume that you have a modern workspace. This type of workspace has four different roles, being

• Admin, can manage the workspace itself, other user permissions and content in the workspace.
• Member, can manage content in the workspace and manage workspace permissions lower than own permissions.
• Contributor, can contribute to content in workspaces, and update the workspace app if explicitly granted permissions to contributors to do this.
• Viewer, can view the content in the workspace in a consume only mode.

Above is a very simplified summary of workspace roles and the basic understanding what we need to understand the remaining of this blog. For exact capabilities per workspace role, please review the permission matrix in this documentation.

Workspace roles in project setups

So far not something really new, but let’s have a look on how you can apply these different roles effectively in your project setup and what challenges you might phase in setting up your workspaces.

Messy workspaces!

At clients, I typically encounter two different patterns. Either the workspace is not shared with anyone, or the workspace is shared with tons of different users. Both are not really what you want. As tenant administrator, you’re already happy that they did use a shared workspace rather than publishing in personal workspaces, so you at least can take over and monitor if needed. Also, good to know for those tenant admins out there, later in 2022 the governance around personal workspaces will be expanded. Microsoft will allow tenant administrators to take over control in personal workspaces. Read more about this upcoming enhancement here.

In part 1 I elaborated on the different sharing mechanisms and how you can publish apps from a workspace to share content in a view only mode. Personally, I take sharing through an app as a best practice and value it above granting workspace permissions. Though, I want to quickly take your attention to sharing once again. I would say, if you share content with your end users, who are intended to only consume the content, always publish an app. This keeps your workspace clean and out of folks that only consume. Especially as you can share a subset of content in an app. You do not necessarily need to share the entire workspace.

If there are tons of users in your workspace, who is keeping control over this. You might have confidential information in that workspace. Even if you applied row level security applied, please know that members, contributors and admins in a workspace overrule applied row level security and they can see everything and even adjust permissions to the model.

Also, I often find many workspace administrators. Even people who are not so mature in their Power BI skills but have the ability to control an entire workspace with an enterprise solution shared across the organization. There are many dangers in this! In the worst case they can accidently remove content. When we start talking about ownership, with many administrators comes the challenge who is really in charge and owns the solution hosted in this workspace? On the other hand, as a Power BI Service Administrator you want to avoid that users start reaching out to you because the admin of the workspace is on vacation and the solution broke, but nobody has sufficient privileges to access and fix it.

Workspace permission principals

To cover above concerns, I have a few basic principles that I always follow with regards to workspace permissions. This all to avoid messy workspaces as described above.

1. Take advantage of Active Directory Groups as much as you can! This keeps a clear oversight in your workspace access setup and avoid tons of named individual users. Preferably these groups are managed through the organization Identity Access Management (IAM) processes and tools.
2. Make sure you apply the “least privilege as possible” principle, to avoid overclassifying users with the risk that they mess with your solution.
3. Users who only consume content, only get access through the Power BI App. Not directly in the workspace.
4. Ownership is at two users at least, but no more than five users at the same time. Only so that ownership is clear and backup is covered in case users are off work and hot fixes are needed.

Who to grant which permissions?

In projects, it is likely to have multiple workspaces as you may have different development stages, each covered in a workspace. In this case, you might be questioning when you should grant which permissions to whom.

Typically, it all starts with identifying who the owner of the solution will be. This is already important at project initiation, but also on the long run as your main stakeholder and the person who is making the decisions. This person needs to always have Administrator permissions at all stages, simply because this person is the owner and end responsible. Also read my earlier blog on ownership of content.

Secondly, you might have a group of key users who are testing your solution before you publish it in an app to the final end users. Personally, I always make sure they have the least privilege as possible. Try to avoid situations where key users start messing with your solution or reshare to others. At the same time, you want to be open to them and show the progress you make. Publishing the Power BI App after every change is not very effective in this scenario. Here, viewer permissions could be the perfect fit! Workspace viewers can consume the content, leave comments on content to provide you with some feedback and see everything that happens inside the workspace.

In case you are co-authoring a solution with others, then make sure that one person is in the lead. This person has Admin permissions, while the others are workspace Members. With that setup, you make sure responsibility is assigned, and at the same time those who are Member can do (almost) everything in the workspace to build and maintain Power BI solutions. Only at finalizing the project and hand-over to the main stakeholder, the Power BI workspace administrator is mandatory to assign additional owners to the workspace to address ownership as explained earlier.

Build permissions and content reuse

In some scenarios, explicit permissions have to be granted. For example, when users need build permissions on your data model so they can reuse your model in their own reports, or if you want to share that one managed dataflow that you host in your workspace.

Dataset build permissions can be added on dataset level directly in the workspace and can be granted as part of the app publishing process. Therefore, nothing really changes. However, for sharing dataflows it is key to split some things up. This all starts at the scope of your workspace as described in part 1 of these blogs on workspace permissions. To shortly repeat;

Power BI Workspace setup – Part 1

Only reports and dashboards can be directly shared with others, but for dataflows such a sharing mechanism does not exist. So, in case you want to share a (set of) dataflow(s) with other users as a central product dimension for example, then you are forced to grant workspace permissions. Only with workspace permissions users can read and re-use dataflows in their solution. This contributes to a rationale for positioning dataflows in a separate workspace than your data model and/or reports.

Sharing only one dataflow is unfortunately not possible. Also, specific security implementations like row level security or object level security do not exist on dataflow level. Imagine you have one workspace containing 10 different dataflows, but you only want to share one dataflow with someone else. You can move this dataflow to a different workspace, but that will complicate your workspace and dataflow management. In this specific scenario, there are a few things you could consider to do;

• You can setup a new workspace where you create a linked entity to your main dataflow in a different workspace. In this scenario you avoid dataflow logic duplication and the dataflow will be kept up to date. Though, keep in mind that linked entities require Power BI Premium. Because of that, this is an expensive solution as you need to have premium in the first place, and secondly each refresh contributes to the capacity utilization.
• As a second option, you keep one definition of your dataflow in source control, Azure DevOps for example. Using release pipelines, you can deploy the dataflow logic to multiple destination workspaces. In this case you have multiple copies of the same dataflow side-by-side in different workspaces. The downside of this setup is that each dataflow runs its own refresh schedule and with that creates an impact on the data source.
• In Power BI you have the ability to grant build permissions explicitly to a user as I explained above. The third option is completely based on this pattern. In case you want to share only one table or a small set of tables with other users, consider doing this through a dataset. By simply creating a role in your data model and configuring Object Level Security, you only grant access to specific elements of the data model. Then you assign build permissions to the user that wants to use your tables and they can start consuming this in their own data models. Users can do this by benefiting from Direct Query for Power BI datasets.

If you are looking for more content on dataflows in specific, I encourage you to read my earlier blog on How to keep your Power BI dataflows organized and optimized.

Wrap up

All by all, there are many things you have to keep in mind to have a clean workspace governance setup. In the first part of this blog series, I covered the generic workspace setup, why you should create a shared workspace in the first place but also covering naming convention and scoping of workspaces. This contributes to clarity and being able to easily identify the intention of different workspaces. In this second part, I elaborated on permissions. The take away I want to highlight once more, is the principal of “least privilege as possible” which should be applied at all times.

Also, Ownership of workspaces should be addressed, while avoiding things getting messy. So, make sure you have a few Power BI workspace administrators, but do not overdo it! These people are the contacts that also must be listed in the workspace contact list. In case something needs attention, these are the people to reach out to. Ownership is an important topic that should also be clearly communicated from the solutions shared with others.

Finally, rethink how you currently shared your content in your organization for reuse. It might be that you granted them more permissions than they need to cause you gave directly workspace access. Or you might have ended up with solution patterns that are hard to maintain due to numerous workspaces on many named users listed in your workspace permissions. Keep in mind that sharing via the Power BI App in combination with Build permissions will do the job as well.