Fabric Workspaces as atomic building blocks

Microsoft Fabric is an integrated analytics platform — and its smallest addressable building block is the workspace. Anyone implementing Fabric makes an early decision that can only be rectified later at considerable cost: how many workspaces do we need, and how do we structure them?

The question may sound technical, but it is fundamentally organisational. A workspace is not merely a folder for artefacts. It is simultaneously a capacity allocation, a deployment unit and a security boundary. These three dimensions are interlinked — and their overlap gives rise to the topology of a Fabric data platform.

This article systematically classifies these dimensions, derives decision-making rules from them, and illustrates what a typical workspace topology looks like for a distributed data product team. It concludes with an observation that extends beyond Fabric: the relationship between workspace structure and organisational structure — Conway’s Law in the data platform.

What a workspace is — and what it is not

In the simplest terms, a Fabric workspace is a working environment in which a team collaborates on a data product or a family of data products. It contains all the associated artefacts: lakehouses and warehouses for data storage, data flows and notebooks for transformation, semantic models for semantics, and reports and dashboards for presentation.

In theory, a complete data solution — from raw data ingestion to the finished dashboard — can be built within a single workspace. This is feasible for prototypes, experiments and very small teams. However, for anything that grows, goes into production or involves multiple teams, problems quickly arise:

A single workspace containing everything mixes load profiles, deployment cycles and permissions. What starts out simply ends up as a structure that is difficult to maintain, in which nobody knows exactly what belongs to which product — and in which every change potentially affects everything else.

The question, therefore, is not whether dividing the system into several workspaces makes sense, but when and according to what logic this should be done. The answer lies in three dimensions.

Three dimensions, one topology

Capacity & Load

Key question: Which workloads run when, and at what intensity?

Typical decision: Separate and assign workspaces according to load profile

Release & Deployment

Key question: What is deployed when, and together with what?

Typical decision: Group deployment units into focused workspaces

Security & Roles

Key question: Who is allowed to view, edit or trigger what?

Typical decision: Set permission boundaries through workspace separation

These three dimensions all affect every workspace simultaneously. A decision that makes sense from a capacity perspective may complicate deployment logic. Fine-grained security separation can cause the number of workspaces to grow exponentially. Good workspace design finds the balance that addresses all three dimensions simultaneously.

Dimension 1: Capacity and load management

Each workspace is assigned to a Fabric Capacity. All workloads executed within this workspace — Spark jobs, pipeline runs, Power BI queries, KQL queries — consume Consumption Units (CU) from the assigned Capacity. The assignment of a workspace to a capacity therefore determines the cost budget and load profile it shares with other workspaces within that capacity.

This has direct implications for workspace design. If intensive batch transformations and interactive BI queries run in the same workspace, they compete for the same capacity.

A nightly load run that ties up all CUs delays users’ first dashboard requests the following morning — until burst debt has been cleared.

Specialised workspaces organised by workload profile solve the problem: ETL-heavy workspaces on a capacity optimised for background workloads, interactive BI workspaces on a capacity designed for fast, short queries. And if a workload profile changes — a product grows, a project ends — the workspace can simply be reassigned to a different capacity without moving artefacts.

Workspaces are the unit used to allocate capacity. By clearly separating workloads, you can effectively manage capacity.

Dimension 2: Releases and Deployment Pipelines

Fabric deployment pipelines link workspaces to form a deployment chain. Typically, there are three stages: Development → Test → Production. A release ‘pulls’ content from the source workspace to the target workspace. What is transported in the process is — at least so far — the entire workspace content: all lakehouses, all notebooks, all semantic models, all reports.

This leads to a clear requirement: a workspace should contain exactly what is to be deployed together and at the same time. If a team wishes to deploy its ETL code independently of its reports — because the reporting is already in production and should not have to wait until the new pipeline code has been tested — it needs separate workspaces for these parts.

This applies regardless of whether deployment is carried out via deployment pipelines or a Git repository linked to the workspaces.

Rule of thumb for deployment: one workspace corresponds to one deployment unit. Everything that coexists within a workspace is released together. Artifacts with different release cycles belong in different workspaces.

In practice, this typically means a separation along the logical layers of a data product: one workspace for data storage (Lakehouse, Warehouse), one workspace for transformation logic (notebooks, pipelines), one workspace for semantics (semantic models, data marts) and one workspace for visualisation (reports, dashboards). This separation also reflects different business responsibilities — which leads directly to the third dimension.

Dimension 3: Security and Roles

Fabric’s authorisation model at workspace level is deliberately kept simple. There are four roles that apply to the entire workspace:

Admin

Can read: ✓ · Can edit: ✓ · Can deploy: ✓ · Can manage: ✓

Member

Can read: ✓ · Can edit: ✓ · Can deploy: ✓ · Can manage: –

Contributor

Can read: ✓ · Can edit: ✓ · Can deploy: – · Can manage: –

Viewer

Can read: ✓ · Can edit: – · Can deploy: – · Can manage: –

This simplicity is both a strength and a limitation. Granular permission control within a workspace is not provided. It is not possible to grant a user group editing rights for specific Lakehouses but not for others, or to allow developers write access to notebooks without simultaneously granting them access to sensitive production data.

Anyone requiring such segregation must set up a more precise allocation using separate workspaces. Typical scenarios requiring security segregation:

Back-end developers vs. front-end developers

Solution: Lakehouse/pipeline workspace separate from the report workspace

Sensitive raw data not visible to all analysts

Solution: Raw ingest workspace with restricted access, curated workspace for analysts

Protect production data from developer access

Solution: Strict stage separation: developers have no access to the production workspace

External partners should only see specific reports

Solution: Dedicated sharing workspace with a ‘viewer’ role for external accounts

A typical workspace topology

If all three dimensions are taken seriously, a medium-sized data product team will quickly end up with a double-digit number of workspaces. This may sound like a management burden — but it is the price to pay for clear boundaries between load profiles, deployment units and authorisation scopes.

The following table shows a typical topology for a single data product (in this case: sales data) with two deployment stages and a supplementary data access workspace:

raw-ingest-dev: Pipelines, event streams, Lakehouse landing zone · Stage: DEV · Capacity: F8 Dev

raw-ingest-prod: Pipelines, event streams, Lakehouse landing zone · Stage: PROD · Capacity: F32 Prod

silver-transform-dev: Notebooks, Spark jobs, Silver Lakehouse · Stage: DEV · Capacity: F8 Dev

silver-transform-prod: Notebooks, Spark jobs, Silver Lakehouse · Stage: PROD · Capacity: F32 Prod

product-sales-dev: Gold Lakehouse, semantic model, data marts · Stage: DEV · Capacity: F8 Dev

product-sales-prod: Gold Lakehouse, semantic model, data marts · Stage: PROD · Capacity: F32 Prod

reports-sales-dev: Power BI Reports, Dashboards · Stage: DEV · Capacity: F8 Dev

reports-sales-prod: Power BI Reports, Dashboards · Stage: PROD · Capacity: F32 Prod

access-finance: Shortcuts, row-level security models, external shares · Stage: PROD · Capacity: F16 Shared

In reality, further workspaces are often added: a test stage as a third deployment stage, separate workspaces for shared semantic models used by multiple products, or monitoring workspaces with operational dashboards. A platform with five data products can easily comprise 50–80 workspaces — this is not a sign of complexity, but of a well-thought-out structure.

Shortcuts as a connecting layer between workspaces

A common question when designing a workspace topology is: if data is distributed across multiple workspaces, how does a downstream workspace access the data from the upstream workspace? The answer in Fabric is the shortcut — a virtual reference to a data store in another workspace that works without copying the data.

Shortcuts allow workspace boundaries to be bridged without duplicating data. A Gold Lakehouse in a product workspace can access Silver data from the Transform workspace via a shortcut. An access workspace for external partners points via a shortcut to selected tables in the production workspace — with its own access control, without a copy.

Workspaces and Conway’s Law

In 1967, Melvin Conway formulated an observation that is now known as Conway’s Law: organisations that design systems produce designs that reflect the organisation’s communication structure. Or, to put it another way: those who build systems that require a specific organisational structure force the organisation to conform to that structure.

In the context of Microsoft Fabric, Conway’s Law takes on a very concrete form. The platform is conceptually designed for distributed, domain-oriented teams. Each workspace belongs to a team. This team bears responsibility for its data product — from ingestion through to consumption. The workspace role (Admin, Member, Contributor, Viewer) is the formal language in which this responsibility is expressed.

Anyone who implements Fabric without altering the organisational structure will be setting the platform up to work against itself.

The tension: centralised organisation, decentralised platform

Many companies start with a centralised data organisation: one team is responsible for all data. This team can still own all workspaces in Fabric — but it must then distribute roles internally in such a way that, in practice, different sub-teams are responsible for different workspaces. This works, but creates a structural tension: the formal organisational structure and the operational workspace structure do not align.

Organisational models and their implications for Fabric

Centralised team, all domains

One team owns all workspaces. Roles are allocated internally. Leads to implicit dependencies and broad permissions. Domain teams, shared platform

Domain teams, shared platform

Each domain owns its own workspaces. The platform team manages capacity and governance. This aligns with the Fabric concept. Hybrid: Centralised + Decentralised

Hybrid: Centralised + Decentralised

Centralised team for the raw data layer; specialist teams for product workspaces. Pragmatic, but requires a clear definition of interfaces.

The practical consequence: Anyone working with Fabric in a centralised organisation will sooner or later notice that colleagues are constantly switching between workspace roles — depending on which workspace they are currently working in. In the sales workspace they are a Contributor, in the marketing workspace a Viewer, and in the platform workspace an Admin. This is not wrong, but it signals a deeper tension between the formal structure and operational reality.

Fabric rewards organisations that structure themselves around their data domains. This is not a technical requirement — it is an organisational invitation. Those who accept it build a platform that grows with the organisation. Those who ignore it build a platform that allows the organisation to grow in spite of it.

Decision-making guide: When to use which workspace structure?

There is no universally correct workspace topology. The right topology depends on team size, the platform’s maturity, compliance requirements and the organisational structure. The following matrix provides guidance for typical situations:

Two teams share data but have different permissions

Recommendation: Separate workspaces with shortcut-based data access

Front-end and back-end developers are working on the same product

Recommendation: Separate workspaces for semantic models / reports vs. lakehouse / pipelines

Similar workloads with very different load profiles

Recommendation: A separate workspace per load profile, targeted capacity allocation

Fast, independent releases for different product components

Recommendation: Model deployment units as separate workspaces

Small organisation, one team, manageable set of artefacts

Recommendation: One workspace per stage — keep complexity to a minimum

Large organisation, many teams, regulated data access

Recommendation: Full Medallion topology per product per stage + access workspaces

A pragmatic starting point: Begin with two to three workspaces per data product and stage — one for data storage and ETL, one for semantic models, and one for reports. This covers the most essential boundaries and can be expanded as required. An over-engineered architecture from the outset paralyses teams just as much as an under-engineered one that later requires costly restructuring.

Conclusion: Topology as a first-order architectural decision

Workspaces are the atomic building blocks of Microsoft Fabric — but their significance extends beyond the technical.

The workspace topology of a Fabric platform is also a statement about how an organisation organises its data work: who is responsible for what, what can be developed and deployed independently, and what boundaries apply between permissions.

The three dimensions — capacity, deployment and security — are not separate issues, but three perspectives on the same fundamental decision: where do I draw the lines? Anyone who focuses on just one dimension during the design phase risks encountering problems in the others. Those who keep all three in mind simultaneously develop a topology that remains stable as the platform and the organisation grow.

And anyone who takes Conway’s Law seriously understands this: the best workspace topology is the one that reflects the team structure you want — not the one you currently have.