The question I often get in my Power BI architecture consulting sessions is; “How should we organize our workspaces? should we have one workspace with all the reports in it? Or multiple? Should we split it based on each report? Business unit? or something else?” In this article and video, I’ll explain a guide on how to organize and set up workspaces in your organization.
Video
What is a workspace in Power BI?
If you don’t know the workspace, read my article here explaining it. In a nutshell, a workspace is an environment to host and share Power BI content. The Power BI content includes but is not limited to; Dataset, Dataflow, Datamart, Report, Paginated Report, Metrics, Dashboard, etc.
Consider a Power BI workspace as a single development-sharing unit.
You can have multiple Power BI objects (dashboards, reports, datasets, dataflows, etc.) inside a workspace, but when you share it, you share all of it. When I speak of sharing, I mean one of the workspaces sharing methods. By using Power BI apps, you can share a subset of the content, and using basic sharing, you can share an individual object. However, I don’t recommend using basic sharing for content in the workspace (unless it is for testing the reports). And for the rest of this article, I do not consider that option for sharing the content of a workspace.
This means that the entire content in your workspace would be shared with someone who has an access role in your workspace (Administrator, Member, Contributor, or Viewer) and a subset of that to the Power BI app users.
You cannot share part of the content of a workspace with some users, and another part of it with other users. The Power BI workspace is one single sharing unit.
Separating audiences with Power BI App
I call a workspace a single development-sharing unit because you can use one workspace for multiple groups of audiences. I explained in this article how you could create multiple audiences and share different content from the same workspace with a different group of users. However, Developers are users with Edit access to the content, which is only for Admin, Member, or Contributor users. These access levels permit the user to access the entire content of the workspace, not part of it. So, the Power BI workspace is one single unit of sharing for developers or data analysts.
Separating developers with multiple workspaces
Based on the above explanation, it is understandable that you will need a separate workspace for a different group of developers (or data analysts). In the below screenshot, if you have two sets of reports which should be shared with two different audiences, you won’t get them all hosted in one workspace.
You need two different workspaces if you have two different sets of reports for two different groups of developers.
Please note that there is a difference between developers and end users. Developers need access to the workspace to edit the content, while the end users will use Power BI apps as an audience. Here I explained different types of users in the Power BI environment.
This means that if you have 12 groups of developers for 12 sets of different reports, then you would require 12 workspaces.
Split the load, Use the capacity
Another important reason for having a separate workspace is to split the load. This is normally the case when you use a dedicated capacity plan (Power BI Premium or Embedded). If you have a very high consumption rate report, you might want to keep it separate from other reports with a low consumption rate and have it hosted in a separate workspace. Because for each workspace, you can choose what dedicated capacity it would be hosted on.
Shared workspaces among multiple developers
I’ve mentioned that one normal practice of having multiple workspaces is having one per developer group. This means, for example, HR reports in the HR workspace and Sales reports in the Sales workspace. However, what if both of those reports use a Date table? Then you need a date table to be accessible for both groups.
Having a shared workspace is an important part of a Power BI architecture. This technique will reduce the redundancy in the implementation, increases consistency, and helps in the overall development process of the Power BI content.
I have explained the dataflow concept in this article if you want to know more about it.
Layers of shared workspaces
The shared workspaces can have more than just dataflows; they can have datasets too. You can have layers of shared workspaces. For example, the Date table is something that probably all other workspaces are using. Still, something like the Account table might be only needed for a handful of workspaces in the organization.
Separating the Environments
Another good use case for having multiple workspaces is to separate the environment. For a proper Power BI implementation (or any other software development implementation), you need to have a different environment for Development, Test, and Production. This has tons of benefits in the development process and will bring trust into the adoption because the content in the production environment will be passed through multiple checks and validations.
The screenshot above is a screenshot of the deployment pipeline in Power BI Premium, which helps you to set up the deployment between the environments. However, even if you do not have the Premium license, you can still use the concept of DEV, TEST, and PROD environments and PowerShell scripts to handle the deployment between them.
Workspaces as development layers
Having the environments of DEV, TEST, and PROD is not the only workspace structure that helps the development of Power BI solutions. There are some other development practices that you can use by separating workspaces. One of them is what I explained in detail in this article.
The above screenshot shows multiple workspaces for staging dataflows and transformations. In real-world scenarios, there can be more than these two layers depending on the complexity of the implementation.
How to organize workspaces in my organization?
To summarize, there are many important factors in the workspace structure. You would need to have separate workspaces based on the analysts’ groups and then sometimes based on the audience. It is recommended to have Dev, Test, and Prod layers through workspaces. You have to consider the usage of shared workspaces to reduce redundancy and increase consistency. You can also split the load on the reports using multiple Power BI workspaces.
As you can see, there is a lot to think about when you design the workspace structure. This is a design that would be different from organization to organization. I usually go through many of these processes in my architecture advisory gigs. So I thought it is better to explain some of them here, so it helps you too. Please let me know in the comments below if you have any questions.
Thanks Reza for another great article. I am wondering about a situation when I have one big report and I need to publish it for several teams (let’s assume 10 groups). Each group has to see a different set of pages of the same report. What is your recommendation in such a case?
Hi Mati
I would suggest using the method I explained here.
This means create a shared dataset in a workspace, and multiple reports to it from other workspaces. each report can be build for the audiences that would see those pages of the report. then create apps from each of those workspaces.
Cheers
Reza
Dear Reza, thanks for this informative article.
Thanks Qmars 🙂
Cheers
Reza
Can’t wait for multiple APPs per Workspace
What do you think about publishing Power BI apps instead of sharing workspaces with end-users? Isn’t this apps concept all about enterprise level Power BI? Why do you not recommend it?
Hi Martin
I DO RECOMMEND using Power BI apps to share the content with the end-users. However, this article wasn’t about apps, it was only about the workspace aspects of things. Even using Power BI apps, you still need workspaces for some parts, and app for the end user sharing.
Cheers
Reza