Microsoft Fabric Workspace Topology Patterns

By James Broome Director of Engineering 9th July 2026 · 6 min read

Workspace topology is one of the first decisions to make when adopting Microsoft Fabric, and one of the hardest to unpick later. This post walks through the common topology patterns that we implement and the decision drivers around each one, starting simple and progressively introducing granularity as complexity and scale demands. Get this right early and the right governance, deployment, and access control models will all flow naturally.

Why Topology Is an Architectural Decision, Not an Admin Task

Workspace topology shapes your security boundaries, determines how independently teams can work, controls what you can isolate from production, and makes cost attribution either transparent or a guessing game. These are architectural problems, not admin problems.

We've seen teams struggle to refactor workspaces after they've gone live because they built everything in one space and later discovered they couldn't deploy changes safely, couldn't give data engineers access without exposing semantic layers to edit, or couldn't track costs by business domain.

Getting topology right at the start means everything else flows naturally - governance decisions inherit from it, your deployment pipeline makes sense, your access control model is simple to manage. Get it wrong and you're making exceptions, working around constraints, and potentially facing rework.

Pattern 1: The Single Workspace (and When It's Enough)

Everything lives in one workspace: your pipelines, lakehouses, dataflows, reports.

This pattern is right for:

• Early exploration and proof of concept
• A single person or a very small team
• Something that hasn't gone to production yet

The advantage is simplicity - no duplication, no complexity, no management overhead.

But the tipping point arrives very quickly, generally in one of three forms.

1. You need environment separation, because you can't test changes without risking your live data.
2. More than one team/person needs to work on the same artefacts, and their access needs diverge (engineers can't be allowed to break reports, report builders shouldn't edit pipeline logic etc.).
3. Your reports start breaking because pipeline changes weren't tested in a safe space first.

When any of these arrives, you've outgrown a single workspace. The good news is the decision to split is usually clear by that point.

Pattern 2: Environment Separation (Dev / QA / Prod)

Separate workspaces per logical environment (relating to stages of the software development lifecycle), with the same artefacts promoted through the pipeline: develop in dev, validate in QA, release to prod.

The bare minimum is two stages (dev and prod) but we'd always recommend at least three. Going straight from dev to prod is a reliable source of production incidents because someone always assumes another environment caught a problem that nobody actually tested. QA (or test, or staging) is where integration issues surface that unit tests miss.

But often, three environments isn't enough. The development/engineering/data team might need a dedicated integration environment to test their changes before sharing with business stakeholders. The business might want a dedicated pre-prod environment to validate changes against live data before promoting to prod. There might be a need for dedicated environments containing specific known sets of data for functional/load/performance testing scenarios.

The key is being clear about the purpose of each environment, and adopting a sensible and consistent naming convention. For example:

The tipping point to move beyond this pattern arrives when multiple independent use cases or business domains start sharing a workspace, because changes to one problem space affect the other, or when your access control needs diverge between them.

Pattern 3: Splitting Data Engineering and Reporting Workspaces

Separate workspaces for data engineering artefacts (pipelines, lakehouses, dataflows) and Power BI reporting, even within the same environment.

This represents a step-change from Pattern 2 because it acknowledges that these aren't the same problem. Data engineers need to move fast and experiment, but report builders need stability and a clean semantic layer. A broken pipeline shouldn't take down a exec report.

Different deployment cadences matter here too. You might deploy data engineering changes several times a day, whereas reporting changes might be monthly. Different governance boundaries follow from that - depending on your Power BI licensing situation (and the nature of your report usage), you might not even need to assign a Fabric capacity to your reporting workspaces (internal users can use existing Power BI Pro licenses).

Building on the environment naming conventions above, we now need to add another dimension to reflect the type of workspace:

The tipping point to move beyond this is when multiple independent use cases or business domains need separate governance tracks, or when noisy-neighbour capacity issues start appearing (compute from one reporting workspace competing for resources with another).

Pattern 4: Use Case or Domain Bounding

Each logical use case or business domain gets its own set of workspaces, rather than sharing a common pool.

A good way to think about this is that you're drawing security and ownership boundaries around a logic business problem and audience. Finance data engineering and supply chain data engineering are different problems, with different owners, different stakeholders, and different compliance concerns. Sharing workspaces between them creates artificial coupling.

Fabric Domains are the organisational layer that sits above this. One Domain per business unit or strategic capability, containing the workspace sets for all the use cases within that unit. This helps to unlock scaling as your Fabric deployment grows.

flowchart TD
    D1["Domain: Finance"]
    D2["Domain: Operations"]
 
    subgraph F1["Use Case: Accounts"]
        direction LR
        F1DE["DE Workspaces<br>dev / QA / prod"]
        F1RPT["Reporting Workspaces<br>dev / QA / prod"]
        F1DE --> F1RPT
    end
 
    subgraph F2["Use Case: Portfolios"]
        direction LR
        F2DE["DE Workspaces<br>dev / QA / prod"]
        F2RPT["Reporting Workspaces<br>dev / QA / prod"]
        F2DE --> F2RPT
    end
 
    subgraph O1["Use Case: Logistics"]
        direction LR
        O1DE["DE Workspaces<br>dev / QA / prod"]
        O1RPT["Reporting Workspaces<br>dev / QA / prod"]
        O1DE --> O1RPT
    end
 
    D1 --> F1
    D1 --> F2
    D2 --> O1

The tipping point is when the data within a single use case becomes large or complex enough that different layers need independent governance or are owned by different teams. At that point, your next step is usually Pattern 5.

Pattern 5: Separating Storage from Compute

The lakehouse (storage) gets its own workspace, separate from the workspace where pipelines and notebooks run.

Storage artefacts have a different lifecycle from compute artefacts. Your raw data warehouse might sit static for weeks, whereas your pipelines running against it might change daily. Separating them means you can govern them independently, upgrade compute logic without touching storage, and give different teams responsibility.

This also enables sharing. Multiple pipeline workspaces can read from a single curated lakehouse without being coupled to the engineering workspace that built it. The reporting workspaces get access to a clean Bronze/Silver/Gold layer without needing to understand the pipeline logic that produced it.

This approach also helps with cost transparency. Storage costs and compute costs separate naturally, making it clear which workload is actually expensive.

flowchart TD
    PA["Pipeline Workspace A"]
    PB["Pipeline Workspace B"]
    LH["Lakehouse Workspace<br>Shared storage"]
    RPT["Reporting Workspace"]
 
    PA -->|Write| LH
    PB -->|Write| LH
    LH -->|Curated data| RPT

The tipping point is when the data volume becomes large enough, or ownership and usage scenarios become complex enough, that different layers need independent governance and different teams managing them.

Pattern 6: Medallion Layer Splits

Bronze, Silver, and Gold layers each in their own workspace.

flowchart LR
    B["Bronze Workspace<br>Raw ingestion<br>Copy jobs"]
    S["Silver Workspace<br>Curation & cleansing<br>Pipelines / notebooks"]
    G["Gold Workspace<br>Semantic models<br>Pipelines / notebooks"]
    R["Reporting Workspace<br>Power BI / consumers"]
 
    B --> S --> G --> R

This applies when raw ingestion, curation, and the semantic reporting layer are owned by different teams or funded by different business units, when the scale of raw data creates genuine noise for downstream consumers (massive ingestion workloads getting in the way of curation), or when you want easily allow and manage access to specific layers of the medallion (e.g. providing Silver layer access for data science experiments).

There's obviously a trade off - more workspaces means more overhead, more complex deployment pipelines, more moving parts to understand and govern.

Most organisations don't need to start here, this is the pattern you reach when the simpler patterns have proven insufficient.

Choosing Your Starting Point

The patterns progress from simple to complex, but also aren't necessarily directly linear. You might need use case bounding before environment separation, or storage splitting before data engineering/reporting splitting. Knowing which to start with matters more than understanding the full spectrum.

In practice, the patterns are more of a multi-select set of options. For anything heading to production, you'll need Pattern 2 (environment separation). If you have any non-technical report builders in the picture, add the DE/reporting split (Pattern 3) from the outset. Both of these are investments that cost very little to implement early but become expensive to add later.

Our typical starting point for any engagement beyond the most trivial is a combination of patterns 2, 3, and 4. Workspaces that are bound by use case, separated by environment, and split out into data engineering and reporting.

This gives you roughly six workspaces per use case: two types (data engineering and reporting) multiplied by three environments (dev, QA, prod).

                ┌─────────────────┐  promote  ┌─────────────────┐  promote  ┌─────────────────┐
Data            │   [use-case]    │ ────────▶ │   [use-case]    │ ────────▶ │   [use-case]    │
Engineering     │   -de-dev       │           │   -de-qa        │           │   -de-prod      │
                └────────┬────────┘           └────────┬────────┘           └────────┬────────┘
                         │ feeds                       │ feeds                       │ feeds
                         ▼                             ▼                             ▼
Reporting       ┌─────────────────┐  promote  ┌─────────────────┐  promote  ┌─────────────────┐
                │   [use-case]    │ ────────▶ │   [use-case]    │ ────────▶ │   [use-case]    │
                │   -rpt-dev      │           │   -rpt-qa       │           │   -rpt-prod     │
                └─────────────────┘           └─────────────────┘           └─────────────────┘

Summary

Workspace topology in Microsoft Fabric is a foundational decision that shapes everything downstream - how you deploy changes safely, how you manage access across teams, and how clearly you can attribute costs to the workloads that generate them.

The patterns in this post represent a progression from simple to sophisticated, but they're not a linear checklist - most organisations will find their home somewhere in the middle. Understanding the obvious tipping points before you start should help you get the right foundation in place early to avoid costly rework.

FAQs