Introduction

Microsoft Fabric encourages a broader audience of people to collaborate on the same platform than what we are used to.

Backend Developers, Frontend Developers and End Users are all logging in to the same website, and the lines dividing where each role starts and stops are more blurred than ever.

A topic which seems more relevant than ever, is the question of how to organize the contents of your Microsoft Fabric Platform.

Last time, we covered the topic of Domains in Fabric, and I argued how you should consider a multimodal approach of having both Source-aligned Domains for your backend work, and Consumer-aligned Domains for your frontend work: https://downhill-data.com/2025/05/06/organizing-your-microsoft-fabric-data-platform-domains/

In this blog, we’ll take a look at the next level of organization: Workspaces.

How many Workspaces should you have?

You are likely familiar with Workspaces as an organizing construct if you have any kind of Power BI experience, and it is a topic which many have strong opinions on – and for good reason! A primary discussion is: How many workspaces should you have?

• Do you want as few workspaces as possible, to make usage and administration of platform as easy as possible?
• Do you want more workspaces to accommodate CI/CD, segregation of duties/responsibilities, or for more permission/security options?

Personally, I like to think of Workspaces like Folders in Microsoft Teams. They are a facilitator of Accesses and Permissions, and for organization of content. And for that reason I am not afraid of a larger number of Workspaces (within reason, of course).

However, I think that there is a second and often underappreciated dimension to the use for workspaces, very similar to the discussion I proposed in the last blog about Domains: Workspaces may also act as a facilitator for Governance – even the governance processes which are “soft” in nature.

In this blog, I’ll try to make the case in favour of defining different “types” of workspaces, which may help you govern your platform.

Defining Workspace Types

Before defining the Workspace Types that you want/need in your organization, you should analyse the needs from a business, technical and governance perspective. Below is a non-exhaustive list of topics you should consider:

• Content: What types on content are we developing on the platform?
• Ownership: Who owns each type of content on the Platform?
• Developers: Which types of people are developing each type of content?
• Users: Who uses each type of content?
• CI/CD: Which environments do we need when developing, and is this the same for all types of development on the platform?
• Deployments: Manual or Automated, and is this the same for all types of development on the platform?
• Versioning: None? Teams/Sharepoint? GIT? Is this always the same?
• Endorsements: Are we looking to validate/promote any of the content being developed?
• Access & Permissions: How do we wish to distribute access and give different permissions to the content types?

While some organizations might be able to find a unified set of rules that all Workspaces on their platform must abide by, I would argue that for 99% of organizations, that is an impossible and unrealistic goal.

Rather, summarizing your analysis, you will likely find that there are different clusters of use cases, which demand different Workspace behaviour to thrive.

At the very least I would be as bold as to assume, that if you have any amount of Self Service ambition in your organization, you will need to distinguish between Workspaces used for centralized development, and Workspaces used for Self Service development.

In broad terms I would equally assume that Centralized Workspaces are strongly governed, and Self Service Workspaces less so. An example of the rules to follow within each type could look as follows:

For many organizations, such a two way split is however not sufficient.

You might have two types of Self Service – One for shareable artifacts with certain requirements in place, and one for full wild west sandboxing with zero support offered.

You might have different tiers of centralized development. Maybe centralized frontend developers don’t need the exact same setup as backend developers.

You might also align your Workspace Types with your Domain Types, if you e.g. have split your Domains between Source-aligned Domains and Consumer-aligned Domains as suggested in my previous blog: https://downhill-data.com/2025/05/06/organizing-your-microsoft-fabric-data-platform-domains/

Most frequently, I see a need for a distinct third category of Workspaces, to accommodate for Decentral Development, that is also not Self Service, but carried out by talented Data Analysts building e.g. widely used Power BI Semantic Models and Reports, based on centralized data. At one recent customer, we labeled this type of workspace a “Governed Workspace”. Below is an example that includes all three types:

But let me make one thing clear. The above types are just examples. Your organization may have completely different users and need completely different workspace types to accommodate them.

The general idea here, is to be pragmatic about your Data Platform.

Sure, Fabric Admins and Product Owners would absolutely love it if everybody would just play under the same heavily governed rules, always using GIT, automated CI/CD, security groups and what not.

But let’s be real. This is not going to happen.

You instead need to find the right governance balance in your platform design, to again make it a system of empowerment.

Implementing Workspace Types

So you identified a number of Workspace Types to implement on your platform. How do you implement them?

Now on a technical level, Workspaces have plenty of settings we can set to make them behave slightly differently, including setup up some of the above, but there is no way to set a “Workspace Type”:

For defining the Workspace Type, you are left with using a strict Naming Convention for your Workspaces, to signal the Workspace Type.

I suggest you to find your own way here. But I like to use prefixes like ‘CEN_WorkspaceX’ or ‘GOV_WorkspaceY’ to make the it easily searchable.

Now regarding enforcing the actual behaviour within a Workspace Type, how do you do that? Unfortunately, while we can use the Workspace Settings to e.g. create a GIT connection, we have no way to use them to really enforce any of our playing rules.

Rather, you need to rely on (largely non-technical) Governance constructs. You need to give people governance responsibility. You need to figure out who in your organisation will perform the following actions:

• Enforcing Versioning/Deployment/CICD practices
• Ensuring content is developed according to development standards
• Auditing Workspace and Item accesses
• Monitoring Content Refreshes and Uptime
• Monitoring Data Quality
• … and likely other things

Reality is, that most organisations don’t employ Governance people who will naturally take on these tasks. You will often need to assign these tasks to regular developers/analysts, who are likely to resist, as they probably don’t enjoy those tasks. But only you will know who in your organisation is capable of doing it.

When that is said, there are two frequent types of Platform Users whom I often see lift Governance responsibilities:

Super Users: If you have a community of Super Users in your organisation, I have seen successful attempts at outsourcing certain governance responsibilities to such a group of people.

Domain Owners: If you as part of your Domain Structure have put people in charge of content in a Domain, they, or another person in the Domain Structure, could also be candidates for outsourcing governance tasks to. This also makes sense if your Workspace Types are somewhat aligned with your Domain Types. Perhaps your Source-Aligned Domain only contains “Centralized” Workspaces, hence playing by one set of rules, while your Consumer-Aligned Domain contains your Self-Service and Governed Type Workspaces.

In addition, you can of course perform some centralized governance, including sharing centralized monitoring solutions with e.g. your Super Users and Domain Owners. I can only recommend using the built-in monitoring tools, or custom built ones, to check and monitor how items are being shared, whether if heavily used reports/models are lacking endorsements and sensitivity labels etc.

Using Endorsements to enforce Governance

Speaking of endorsements. One unsung hero of Governance Enforcement that deserves special mention here is exactly Endorsements.

While they are themselves a Governance Construct that need a process around them, they can also help enforce many of the other topics.

I find that the best approach to Endorsements is agreeing on a list of Requirements that e.g. Lakehouses, Semantic Models and Reports need to live up to, in order to achieve the different levels of endorsement: Promoted, Certified and Master Data.

I usually recommend starting with the Checklists created by Kurt Buhler (Power BI Checklists — DATA GOBLINS) and making adjustments to fit your needs.

As part of your checklists you could have as a requirement that:

• Promoted Models need to have Versioning in place, while only Validated Models need Deployment Pipelines.
• Promoted Reports need to follow company design templates while Validated Reports need to check all accessibility boxes.

The above are just examples, but the point is, that you can wave the Endorsement Carrot in front of Power BI developers to encourage them to follow the practices mandated by Workspace Types.

Conclusion

While “Workspace Type” is not a technical term, I highly recommend creating your own definition, to enable categorization of content and users in Workspaces that play by different rules.

This for example also allows you to let Workspaces play differently depending on its associated Domain, or let Centralized and Decentralized efforts work slightly differently.

Ultimately, it is up to yourself to define which and how many Workspace Types are needed in your organization, and also how to anchor the necessary Governance Processes to keep each Workspace type in check.