Power BI Workspace Planning Criteria

Post last updated: September 22, 2022

How to organize workspaces in Power BI is one of those topics that comes up a lot. On one hand, it’s really easy to quickly create a workspace and keep moving. At the same time, it’s also really useful to have a strategy for how you scope your workspaces so they don’t get out of hand over time.

In this post & video we’re going to cover 4 sets of criteria to consider when planning for workspaces in the Power BI Service.

Do you prefer a video or reading text? I’ve got you covered with both below.

The following video is a sample video from my Power BI Deployment & Governance course from a module called Power BI Workspace Purpose, Scope & Organization. Jump to 3:20 in for the specific conversation about the 4 criteria discussed in this post.

 

Four Interrelated Criteria for Power BI Workspace Planning

There are four ways to think about scope when planning for workspaces:

Summary of the Power BI Workspace Planning Criteria discussed in the remainder of this post

If you allow any of your Power BI users to create a workspace: I recommend that you provide guidance and examples to help them save time, and to align with your organization’s preferences in this area. This will promote consistency too, which is good for everyone.

If you have creation of workspaces limited to a specific subset of people: These are the people who need to be well aware of the workspace guidelines and preferences (plus the stricter governance requirements if you have them).

If you have a form people submit to request workspaces: You need to ask enough questions to make good decisions and evaluate the request before it gets created. (Psst…one of the templates in my Power BI Deployment & Governance course focuses on this exact thing.)

Keep in mind all of the criteria are highly inter-related, and will also depend on your approach to governing workspaces. There’s also not necessarily one single answer for the entire organization - there might be an acceptable range of approaches used by different teams or for certain use cases.

The remainder of this post will elaborate a bit on the four criteria.

1 - What is the Content?

Criteria 1: What is the content? Here we are considering the subject area, topic, and purpose which will determine how wide or narrow the scope of the workspace is.

We don't want the scope to be too broad, because we could end up with a huge number of artifacts in a single workspace. This makes it harder to use. If you’re finding yourself being strict with naming of artifacts inside the workspace, that might be an indicator the workspace scope is too wide.

We don't want the scope to be too narrow, because then we end up with a lot of workspaces with very few artifacts in them. Although we have search capabilities, having an ultra-long list of workspaces reduces usability.

Decisions around subject area, topic, and purpose will impact the name you select for the workspace. More helpful information to clarify intent can (and should) go into the workspace description, which users can see in Power BI.

Since Power BI Goals and Scorecards often span multiple subject areas, it’s possible that you’ll decide it’s best to provide them their own workspace.

We also want to think about how sensitive the content is. If it's highly sensitive, then we're more likely to segregate it into its own workspace. In that case, another new workspace is usually worth the trade-off.

2 - Who’s the Content Delivered To?

Criteria 2: Who's the content delivered to? For our subject area (from criteria #1 above), we need to think about the content delivery scope for our target audience. This is REALLY important because this forms an important security boundary.

We also have to consider the license mode for the workspace, which is either Pro, Premium Per User (PPU), Premium Per Capacity or Premium from Power BI Embedded. The license mode impacts which features are available for the workspace (such as deployment pipelines or paginated reports). The license mode also has a big impact on user access. The two biggies related to user access:

  • PPU workspaces can only be accessed by PPU users; this includes access to all downstream artifacts from an artifact that originated in a PPU workspace

  • Premium Per Capacity (a P SKU) is the only one that allows read-only viewers with a Free license

Here's where we also want to think about our intentions for distributing content via an app. Sometimes we “back into” the scope of a workspace because of the app scope and permissions that we want to end up with. However, now that we can have multiple audiences per app, in some cases you’ll be able to simplify your workspace structure. There’s still one app per workspace - that hasn’t changed. But now you’re able to mix and match what workspace artifacts are exposed to an audience, and set the permissions for that audience to different users and security groups.

There might be other licensing implications as well, based on integration with other tools. For example, if you intend to embed a Power Apps visual in a Power BI report then you’ll need to think about Power Apps licensing as well. Granted, this might not always strictly be a workspace-level decision — but depending on how you’re organizing reports in workspaces, it might be easier to license everyone who has access to view content in the workspace.

3 - How Will the Content be Managed and By Whom?

Criteria 3: How will the content be managed and by whom? Here, we're thinking about content ownership and management, which is an important thing to think about alongside content delivery scope (from criteria #2 above). Especially when all artifacts in a workspace are managed by a decentralized team, for instance.

One place a lot of people start is having one workspace per department / team / group. Although that can work sometimes, it often turns into a scope that's way too broad. So, I encourage you to consider workspace organization in a way that does not align with your org chart.

Since we have no folders to sub-organize content within a workspace, if we get past a certain number of artifacts in the workspace it gets very unwieldy. However…keep an eye on this item on the Ideas site which has thousands of votes. I’m keeping the hope alive!

We also think about the type of content, particularly if we're going to separate data workspaces (containing datasets and/or dataflows) from reporting workspaces (containing reports and dashboards) which has great advantages around permissions management and clarity on who manages the content. There is a 10 GB size limit per workspace in shared capacity to be aware of here as well for the data workspaces.

4 - How Will the Content Be Deployed?

Criteria 4: How will the content be deployed? This is where we also think about if we need separate workspaces for development, test, and production.

We want to think about our ALM (application lifecycle management) needs. This is important because (frequently) content is deployed collectively as a group of artifacts. We might also deploy content individually. This could be done manually, with deployment pipelines, with REST APIs, or even with Azure DevOps Pipelines. Which of these methods we use relies quite a bit on criteria #3 above (who is responsible for managing the content).

It's also a good time to think about any other specific needs, such as data sovereignty -- that is, if we need to store the data in a certain place geographically. That would require the multi-geo feature available with Premium per Capacity (i.e., full capacity with a P SKU not with PPU).

You might also need to consider if there’s a technical limitation to consider. Examples:

  • Right now there’s a limitation that either a streaming dataflow or a regular dataflow can exist in a workspace, but not both. Personally I hope this is a temporary limitation not a permanent one.

  • There’s currently a limitation that a deployment pipeline can’t deploy more than 300 items (which is another great reason to avoid having a large workspace with a huge number of artifacts).

  • A workspace can contain a maximum of 1,000 datasets or 1,000 reports per dataset.

Like this Content?

If you’d like even more details on how to plan for workspaces, including a customizable template that includes what information to capture for new workspace requests, check out our Power BI Deployment & Governance training course.