October 15, 2026
Draw boundaries, not org charts.
Workspace design is one of the most important and most overlooked decisions in a Microsoft Fabric platform. Get it right early and security, releases and cost allocation fall into place. Get it wrong and every later change gets harder.
Why workspace topology matters
Workspaces look like an admin detail to sort out after the "real" architecture. That assumption is expensive.
The workspace is where security, capacity, lifecycle, networking and governance boundaries are set. It deserves the same deliberate thinking as storage, ingestion and modelling.
It is also hard to change later. Restructuring a live estate means re-pointing shortcuts, reassigning access and rebuilding Git and deployment pipelines while users depend on the current layout.
Sprawl starts innocently: one workspace for the proof of concept, then one per team, layer and environment. Eighteen months later there are sixty, nobody knows which lakehouse is the source of truth, and a simple release touches six of them.
The fix isn't a magic number. It's clarity about what a workspace actually is.
What a workspace really is
A Fabric workspace isn't just a folder. It is where five controls meet.
| Control | What it means in Fabric | Cricket equivalent |
|---|---|---|
| Access | Workspace roles (Admin, Member, Contributor, Viewer) apply to every item in it. | A dressing-room pass: once inside, you can reach every kit bag. |
| Capacity | Each workspace runs on one capacity, which sets whose compute is used and what competes for it. | Booked practice nets. Two teams sharing one net wait for each other. |
| Lifecycle | Git connects a workspace to one branch; each deployment pipeline stage maps to one workspace. | Nets, practice match, real match. Each stage has its own ground. |
| Network and identity | Private endpoints, workspace identity and network controls are set per workspace. | Stadium accreditation: each enclosure has its own gate and pass list. |
| Governance | Workspaces are the unit you assign to Fabric domains. | Players registered to a state association under the national board. |
Every new workspace draws a boundary for all five at once. Hence the core principle:
Create a new workspace only when at least one of these five controls genuinely needs to be different.
Six common topology patterns
Most Fabric estates use one of six patterns, or a combination.
Figure 1: Six Fabric workspace topology patterns
1. Single workspace
Everything in one place. Fine for a proof of concept or a small team. It breaks once you need separate dev and prod, or users who see reports but not raw data.
2. Workspace per environment
Separate Dev, Test and Prod workspaces, connected by Git and deployment pipelines. This is the minimum for production. It separates change from use, but not engineering from consumption.
In practice: names like sales-eng-dev, sales-eng-test and sales-eng-prod make environments obvious. Dev links to a develop branch, and a three-stage pipeline promotes Dev → Test → Prod, with deployment rules swapping connections per stage.
3. Engineering and consumption split
In each environment, one workspace holds pipelines, notebooks and lakehouses; another holds semantic models and reports, usually published as an app. Business users never get a role in the engineering workspace. For many organisations this is the sweet spot.
In practice: finance-eng-prod holds the lakehouse and notebooks, owned by data engineers. finance-bi-prod holds the model and reports, published as an app to a Finance audience.
4. Workspace per medallion layer
Bronze, Silver and Gold become separate workspaces, linked by shortcuts. Each layer gets its own security and ownership, and ingestion can run on separate capacity. The cost is three times the workspaces and cross-workspace references in every deployment.
5. Workspace per domain
Each business domain, such as Finance or Supply Chain, owns its workspaces under Fabric domains. This suits federated or data mesh models, but only where each domain has a real team.
6. Hub and spoke
A central team owns shared, conformed data (customer, product, calendar) in a hub. Domains consume it through shortcuts, not copies, and build their own products on top. Many mature estates end up here.
Patterns combine
These are building blocks, not exclusive choices. Patterns 5 and 6 almost always sit on top of patterns 2 and 3.
A central raw data hub
For one of our customer, we built a single Raw workspace for the whole organisation. Every source landed there once, and nothing else lived there. Each domain then created shortcuts to the data it needed: no copies, no second ingestion pipeline.
This combines patterns 4 and 6: raw data is centralised, curation and consumption are federated. Why it worked:
- One ingestion path. Each source is landed once, by one team.
- One copy of raw data. Shortcuts reference data in place, so every domain shares one source of truth.
- Clear ownership. The central team owns ingestion; each domain owns what it builds on top.
What to design for:
- Access. The hub holds everything, so domains should reach only the data they are entitled to.
- Change management. A hub schema change hits every shortcut. Agree versioning and communication up front.
- Capacity. Storage sits in the hub, but queries run on each consuming workspace's capacity. Size accordingly.
Do the maths before you commit
Workspace counts multiply. Four domains, three layers and three environments make 36 workspaces before any feature workspace. Each needs roles, capacity, a Git connection, a pipeline stage and an owner.
Choose layered or domain topologies deliberately, and automate provisioning with the Fabric REST APIs or CLI from day one.
A sensible default
Without strong reasons otherwise, start here:
- Separate workspaces per environment, with Prod on its own capacity so dev work can't throttle it.
- Split engineering and consumption within each environment.
- Keep medallion layers as lakehouses inside the engineering workspace, not separate workspaces.
- Assign workspaces to Fabric domains from day one, even with one central team. Adding domains later is harder.
For one domain, the default looks like this:
| Workspace | Holds | Who has a role | Capacity |
|---|---|---|---|
| sales-eng-dev | Pipelines, notebooks, bronze / silver / gold lakehouses | Data engineers | Shared non-prod |
| sales-bi-dev | Semantic models, reports | BI developers | Shared non-prod |
| sales-eng-prod | Same items, promoted by pipeline | Platform team, service principal | Dedicated prod |
| sales-bi-prod | Models and reports, published as an app | BI admins; business users via the app only | Dedicated prod |
Test mirrors Dev on the shared non-prod capacity.
When to break the default
- Split layers into workspaces when raw data is more sensitive than curated data, different teams own ingestion and curation, or ingestion needs its own capacity.
- Go per-domain when domain teams build and release independently. With one central team, it only adds overhead.
- Isolate a workspace when it has unique network needs, such as private endpoints nothing else uses.
- Split by capacity when a business unit funds its own capacity and needs chargeback.
Anti-patterns to avoid
- A workspace per report. Sprawl with no useful boundary. Use apps and audiences instead. Like a separate dressing room for every batter.
- Production content in My workspace. It can't be shared properly or connected to Git, and it depends on one person. If that player is injured, the team's kit is locked in his bag.
- Business users as Viewers on the engineering workspace. Roles cover every item, and Viewers can typically query raw data through the SQL analytics endpoint. Like handing spectators dressing-room passes to read the team sheet.
- Copying the org chart. Reorgs happen far more often than platform redesigns. Captains change every few seasons; you don't rebuild the stadium each time.
- Many workspaces, no automation. Manual setup drifts within months.
The honest trade-off
Fewer workspaces mean simpler deployments but coarser security and shared capacity. More workspaces mean cleaner isolation, but more governance and release effort.
The right topology is the smallest set of workspaces that gives you the boundaries your security, lifecycle, capacity and ownership actually need. Like a good team selection: exactly the players the conditions demand, no more, no fewer.
How Bitwise can help
Bitwise's Data and Analytics practice designs and implements Microsoft Fabric estates, from workspace topology and governance to automated provisioning, CI/CD and migration. Planning a Fabric rollout, or untangling an estate that has outgrown its first design? Talk to our team.
What topology are you running, and why?
