October 5, 2022

Power BI Workspace Strategy for Self Service within Premium Capacities

By Gavin Pedersen

When deploying Power BI, it is common for organizations to overlook having a strategy for what would seem to be a simple task – creating workspaces. It is important for organizations to have a strategy for partitioning workspaces to avoid big problems down the road. 

As consultants, we’ve come across many organizations that have simply purchased and issued licenses for their teams without putting any real thought into how their Power BI environment should be organized and managed. 

There are many different strategies for setting up workspaces for your Power BI Premium Per Capacity (PPC), in this blog, we will cover what we have found to be the most successful ways of doing this.

What Are the Important Considerations Before Selecting a Workspace Strategy?

First, let’s define a few terms that are important for this topic:

  • Capacity: a dedicated set of resources reserved for exclusive use by an organization. With a Premium Capacity SKU, organizations pay for one or more dedicated capacities.
  • Workspace: workspaces are shared containers for Power BI content such as datasets, reports, and dashboards. They are created within a single capacity.
  • Power BI Dataset: a data model stored in Power BI Service that is ready to connect to and make visualizations from. Oftentimes a dataset is built in conjunction with a report. Power BI admins have the ability to give access to the dataset for users to connect to (more on this later).
  • Report: a view of a dataset using various visualizations, commonly referred to as a dashboard.
  • Workspace App: a wrapper for reports in a workspace that is distributed to end users in a single UI.
  • Azure Active Directory (Azure AD): access groups created in Office 365 that are used to manage user access to Microsoft cloud products such as Power BI Service

Before selecting the workspace strategy that best fits your use case, there are a couple of key considerations to keep in mind. These are considerations that should be discovered in capacity planning sessions before a strategy is implemented. No matter what your answers to these questions are, either strategy presented below may work, it will just determine how exactly you implement the strategy.

What Size Should the Capacity be and How Many Do I Need?

As previously mentioned, a capacity within a Power BI tenant is a dedicated set of compute resources for an organization. Non Premium Capacity licenses share these resources with other organizations. There are five Premium Capacity SKUs available (P1-P5), each provide a different amount of memory and cores for computing, and each has a different price. 

In theory, a Power BI tenant can have as many capacities as is required by the use case. Deciding what size the capacity should be and how many you need is an important determination that needs to be made. It should be noted that no matter how many capacities a company has on their Power BI tenant, they are all set up and administered from the same admin portal within Power BI service.  

The size of a capacity should be determined by both the size of the datasets as well as the amount of compute power required to execute the queries. No matter what size you end up selecting, make sure to consider not only the current state but also allow for future scaling, preferably during capacity planning sessions.

Sometimes, it will be necessary to purchase more than one capacity. Examples of when multiple capacities may be required include:

  • If your organization needs to supplement an existing P5 SKU because that capacity has run out of resources.
  • If the user groups are split up by business functions that are large enough to justify their own capacity. In other words, do they have large enough reports that the storage limitation(s) alone is reason enough to have their own capacity? This may especially be true if each business function has its own dedicated reporting team. 
  • If business groups using the same Power BI tenant operate under a chargeback model where they are allocated and are responsible for their own budget used for reporting.
  • If your organization has user groups in different geographic locations. When setting up a capacity, the admin will select a geographical region where the cores are located. Having cores in a location closer to where the user groups are can help reduce latency.

How Many User Groups Do You Have?

The first consideration is who your users are and how many different user groups you have. User groups in this context refer to groups of people who require different views of data, or in some cases, different data altogether. Below are three examples of how you can think about user groups.

  • Business Functions: are you catering to multiple business functions, i.e. sales, supply chain, finance, HR, etc.?
  • Business Teams: are you building reports for a single business function with multiple teams? An example of this would be different order fulfillment methods within the supply chain business function, i.e. in-store pickup, curbside pickup, home delivery, etc.
  • Location: is your team implementing solutions for a business function or business team that needs to see the data differently depending on geographical locations?

The reason this is important is that it will either determine the number of workspaces you provision, or the number of audience views you create within a single workspace app (or both). More on that to come in the next section about the different strategies we recommend.

Is Row-Level Security (RLS) Required or is it an Option?

RLS is a way of implementing horizontal limitations on tables in a data model. In other words, RLS limits the rows in a table an end-user can see based on specific criteria. An example of this is building a sales dashboard for regional managers. Using RLS, you can limit the data the managers see to only include geographic regions relevant to them. 

This is important for the same reason the previous question about audiences was important, it could determine how many workspaces or audience views you will need to create. 

Refer to this blog post on how to set up row-level security in Power BI if your use case calls for it.

What are Power BI Premium Workspace Strategies?

Deciding on a workspace strategy is a critical step in setting up a Premium Capacity for your organization. Leveraging the appropriate strategy that enables self-service will result in the best overall experience for developers and end users. Self-service in this context means a couple of different things:

  • Centralized Reporting: The ability for end users to access reports for day-to-day analysis. This is done by providing access to workspace apps.
  • Self-Service Data: The ability for end users to access datasets to conduct their own ad hoc reporting. This is achieved by giving access to an app’s underlying datasets, a setting found in the workspace app settings page.

It’s important to call out that neither strategy is inherently better than the other and that the strategy your organization selects is entirely dependent on the use case.

Strategy #1: Separate Workspaces for Each User Group

The theme of this strategy is separating datasets and reports that are relevant to different user groups into their own workspaces. Typical user groups relate to things like business function or region, meaning if you have four user groups, you will have four workspaces. 

Keep in mind that you can also create multiple audiences per workspace app. For example, if you have a workspace for each business function and your sales team is divided into regions, you can create a different audience for each region with their own reports within the same workspace app. 

We primarily recommend this strategy for organizations where the different user groups don’t have a lot of overlapping data. 

A simple diagram showing two types of groups, Finance and Sales.

The benefit of this strategy is managing access to reports and underlying datasets is easier because the content is already in separate workspaces. A potential drawback is that the Power BI admin team will have more workspaces to manage. 

Strategy #2: Shared Workspace for Multiple User Groups

With this strategy, user groups will share a workspace. In the previous example, business functions had their own independent workspace. With this strategy, Sales and Finance are combined into one workspace. If this strategy is selected, you can still easily create different audiences within the workspace app to keep the business functions’ reports separate (ten audience limit). 

This strategy is recommended for organizations where user groups have overlapping data and can therefore decrease redundancy by having either fully or partially shared datasets.  However, you could also completely separate the datasets within the same workspace as well.

Another simple diagram showing how a shared workspace for multiple user groups would look like in Power BI

The benefit of this strategy is that there are less workspaces and less content for the Power BI admin team to manage. The drawback is because content is in a single workspace, you will need to be very careful with how user groups are provided access to the content relevant to them. The strategy is primarily recommended for organizations where the different user groups have overlapping data and can therefore decrease unnecessary redundancy. 

Keeping Environments Separate

No matter which strategy is implemented, following a typical development lifecycle is a best practice. Having separate environments for development, test/UAT, and production is important because it builds trust in the reporting and therefore increases user adoption.

To achieve this, one workspace for each stage of the development lifecycle should be created with appropriate access provisioned.

  • Development Workspace: Used for ongoing development of existing and net new Power BI content. Workspace Admin privileges should be provisioned and developers should be given Contributor access so they can publish content from Power BI desktop to the workspace.
  • Test/UAT Workspace: Primarily used by testers to perform data validations and dashboard functionality testing. Workspace Admin privileges should be provisioned and developers should be given Viewer access so that they can view and interact with the content in the workspace but not publish directly to it. Testers should be granted access to the workspace app for functionality testing. If end users will be given access to the underlying dataset in production, the testers should also be given this access to perform data validations.
  • Production Workspace: Strictly reserved for production ready datasets and reports or workspace apps. Workspace Admin privileges should be provisioned and developers should be given Viewer access so that they can view and interact with the content in the workspace but not publish directly to it. End users should be granted access to the workspace app with the option to turn on access to the underlying dataset if that level of self service is required.

Power BI makes it easy to promote content between the environments with Deployment Pipelines. This is a feature in Power BI service that requires a premium license and is designed to be an efficient and reusable pipeline that automates the movement of Power BI content through the development, test, and production workspaces.  

Access to Deployment Pipelines is separate from access to workspaces and should be limited to a select group of people like workspace admins and lead developers. Being selective about who has access to the Deployment Pipelines, as well as limiting developer access to Viewer in the Test/UAT and Production workspaces, minimizes the possibility that a dataset or report will be overwritten, lost, or prematurely promoted to the next stage. 

Check out this blog for more information on Power BI Deployment Pipelines and how to set them up. 

A screenshot showing the Development, Test, and Production process of Power BI.

Pro Tip: Although access to workspaces and deployment pipelines can be provisioned on an individual basis, using security groups like an Azure Active Directory to manage those roles is highly recommended.

Optional Addition to the Strategies - Separate Production Workspaces for Datasets and Reports

Some organizations prefer to have an added layer of security by keeping the production dataset separate from the production reports/workspace app. This option can be implemented with both strategies presented above. However, because you’re introducing an extra workspace, Deployment Pipelines will not be available since they require exactly three workspaces.


Ensuring that your organization has a strategy in place for partitioning workspaces is crucial for the continued success of your Power BI reporting environment. Hopefully you found some of the suggestions and strategies in this blog useful for your Power BI deployment. 

Make sure to contact us if you have any questions or need help with your current Power BI environment. If you could use some extra help, our expert Power BI team would be happy to assist!

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

Accelerate and automate your data projects with the phData Toolkit