Time for a more governance related blog this time. It will be a series of two blogs, where in this first part, I will elaborate on the overall setup of your Power BI workspace and naming. The second part will continue about workspace permissions, sharing and ownership. I feel this is a wide topic and therefore deserves a separate blog.

In this part, focus on the overall setup of workspaces. In my work at various clients, I regularly encounter situations where there is a lot of confusion around workspaces, the scope of a workspace, audience and naming. A blog not only for Power BI tenant administrators, but also for passionate Power BI content creators to better understand each other’s standpoints.

Who can create a workspace?

In various organizations, I have seen administrators blocking workspace creation. Let’s take this as a first focus point. Honestly, in one of my first assignments at a bigger organization, I did the very same thing. We decided to block workspace creation and we wanted to have everything in our own control.

A bit of classical thinking is my judgement about that situation now. I learned from it, and now the very first thing I advise organizations is to open up workspace creation for the entire organization! But why?

The passionate content creator
Let’s write-up a typical scenario. As a Power BI content creator, self-service or part of a BI department, you are proud of your work, and you want to share your insights with other folks in the organization. You do not want to be blocked by that tenant admin that keeps everything in his control. When you finished your report or dashboard, you will share it with others, no matter what or how…

As workspace creation is blocked for you, you start publishing your content in your personal “My Workspace”. Since every Power BI user has a “My Workspace” you can always publish it there, and there are no controls for the tenant administrator to disable or block this.

Honestly, this is still the best scenario that could happen when workspace creation is blocked. I have also seen alternatives where people started sharing editable pbix files on SharePoint and OneDrive locations, or even worse… start distributing the pbix file or screenshots of the report via mail.

The tenant admin
Let’s switch roles and move into the role of the tenant admin. You tried to keep control over everything happening in Power BI, and you thought you did the right thing by blocking workspace creation. Cause you aimed for a single source of truth and only managed and governed workspaces. However, you did not have any control over those passionate content creators who found their way around your governance.

When you disabled workspace creation, the button “Create workspace” is still available in Power BI. At the moment of writing this blog, there is no way to redirect this button to your own governance site or Workspace request form if you will. Your users will have a bad experience and are stuck. They are motivated to get their content shared, so will find a way to do so.

As a tenant admin, you setup various monitoring mechanisms to monitor your Power BI estate. You can see what is inside workspaces, which users have access etcetera. So far, so good. If these users publish their content in their personal workspace, you can still see this content via your admin controls and using Admin APIs. However, you are losing all control when users start distributing content outside of the Power BI Service.

Okay, Personal workspaces are not so bad right? Well… think again. If your passionate user leaves the organization, or in a more positive sense, is enjoying his well-deserved holiday. The content lives in their personal workspace which is not accessible to anyone else. So, in case of refresh failure or other issues nobody can fix it and people might lose their source of information, that one report! With shared workspaces, the workspace ownership can be shared with others who can take responsibility. Also, as a tenant administrator, you can assign others (or yourself) to that workspace from the admin portal in case something needs to be investigated.

Power BI tenant administrators, think again… do you really want to block workspace creation?

Scope of a workspace

Second topic, the scope of a workspace. Often, I encounter situations where a single workspace is created for a department. Sometimes multiple workspaces are available, split in the different development stages being Development, Test, Acceptance and Production (or a subset of).

Points of attention
This is not something good or bad. But it depends… (typical consultant answer). There are many things you should keep in mind when you setup your workspaces. Like the way how you want to share your content, and permissions you might want to grant to others. Sharing and permissions will be covered in part two of this blog. However, I would like to make you aware of a few things already;

• Sharing content from the workspace directly can become messy. It is very challenging to maintain permissions on individual items in workspaces.
• Sharing content through an app can only be shared with one audience. There is a 1-on-1 relation between a workspace and an app. In no way you can publish multiple apps from a single workspace.
• When you share content on workspace level, users can see all content that resides in the workspace. Including all underlying dataflows etc.

That last point on dataflows, is also an interesting one. 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.

Audience
With above in mind, think about who your audience is for the solution you are developing. Do you have an open organization where all HR reports are shared with all HR employees? Or is there a granularity where not all HR employees are allowed to see all information? In that case, you can still limit data by setting row or object level security on the data model. Unauthorized users will find an empty report. In case you want to fully hide the reports, then think about moving them to a different workspace (and with that a different app).

Stage
Important is also a clear split in the workspace development stage. Typical stages are Development, Test, Acceptance and Production or a subset of this. These stages can easily be managed by leveraging Power BI Deployment Pipelines, if you have Premium at your hand. Or managed through Azure DevOps pipelines if you are familiar with that or a combination of both.

Key is the clear split in these stages for your workspace. You want to avoid introducing issues in your production dataset, while you are developing. For smaller solutions, you can consider creating the split in development and production in the same workspace, by applying a pre- or suffix to the artifact name. However, this is more error prone than a split in separate workspaces.

If you want to read more about a multi-tier setup and each potential stage, I encourage to read this blog. It is a bit older, but still applicable.

Naming of workspaces

All mentioned before, argues for more workspaces. Though, you do want to keep control over your workspaces. Also, you want to identify them easily by the name. Below a list of typical topics (in random order) of what you want to have covered in your workspace name. Depending on your organization type, several items can be more or less important.

• Stage
  For example:
  – Development = DEV
  – Test = TST
  – Acceptance = ACC
  – Production = PRD
• Department, full name or abbreviation
  For example:
  – Human Resource = HR
  – Finance = FI
• Initiative / project name or abbreviation
• Country or Operational Company name, code or abbreviation.
  For example: Country ISO codes.
• Text that explains the solution

I have tried up to 100 characters in a workspace name and that worked. I did not encounter a limit in number of characters or anything. Though, think about readability of your workspace name. Therefore, I suggest to not use full names or above-mentioned items but aim for abbreviations. In general, the first 25 characters are the easiest to read from the workspace menu.

For better readability, I suggest adding a few dashes to the name. The order of items to highlight in a workspace name can be changed up to your own preference or company standard. However, I personally think it is important to keep the general elements in the first characters and add the stage identifier in the end. With that, all workspaces belonging to a single solution are listed in underneath each other, with only the stage different.

Let’s take a few examples of workspace names below;

CA-FI-Balance sheet-PRD

• Country: Canada
• Department: Finance
• Initiative: Balance sheet
• Stage: Production

BE-HR-Holidays-DEV

• Country: Belgium
• Department: HR
• Initiative: Holidays, employee holidays
• Stage: Development

In above examples, I did not include any additional explanatory information. I think these spoils the clear and structured naming. Therefore, I add more explanatory descriptions to the workspace description. When you create a Power BI workspace, you can directly add a description to it. You can also do this later or apply to already existing workspaces. Furthermore, you can add an icon to the workspace, which will show in the workspace menu and also in the published App from the workspace.

Good to know, is that the workspace name is not necessarily the name of the published app. Previously, this was the case. But nowadays, you can rename an app before you publish it. In above example, the published app can be named something like “HR-Vacation Days” as the app does not necessarily need to reflect the same elements in the name. Here I do take the assumption that you only publish an app with production content. If you also publish apps for previous stages, then make sure this is recognizable in the app name as well.

Back to the Power BI tenant administrator for a moment. If you allow everyone in the organization to create workspaces, you cannot control the workspace naming convention either. I would say, you should not bother to much about this. Share the naming convention best practice with them, or even a naming convention workspace generator if you will. The only moment you can and should control workspace names, is when people onboard their workspaces to your premium capacity. At that moment, you can ask them to apply to your standards if you are administering and monitoring the premium capacity.

Wrap-up

No matter who you are, a passionate Power BI content creator or a Power BI tenant administrator, I hope each of you better understand each other’s perspective. For those admins, please rethink if you really want to block workspace creation and what exactly is your rational behind it. For those passionate users, please consider adding some common patterns to your workspace name and think about the audience of your workspace!

In part two of this blog, I will continue the story around workspaces, but will zoom in on permissions. In this blog I already highlighted shortly the differences in workspaces and apps. Part two will also include more around how to deal with stakeholders, key users, and ownership of workspaces.