Pros

• Fast time to value No architectural decisions to agonise over upfront. Create one workspace, start building. You can always restructure later once you understand your actual usage patterns.

• Simple security model One workspace means one set of permissions. You assign workspace roles (Admin, Member, Contributor, Viewer) and you're done. No need to manage cross-workspace access or maintain multiple permission sets.

• No shortcut management When everything is in one place, items reference each other directly. You avoid the complexity of creating and maintaining shortcuts between lakehouses across workspaces.

• Easy discoverability For small teams, having everything visible in one place reduces confusion. No hunting across workspaces to find where something lives.

• Single deployment pipeline Fabric deployment pipelines operate at workspace level. One workspace means one pipeline to manage, with all items moving through Dev → Test → Prod together.

 

Cons

• No capacity isolation All workloads share the same capacity. A heavy data pipeline can starve report refreshes, or a surge in report usage can slow down engineering work. You have no lever to separate them.

• Coarse access control Workspace roles are all-or-nothing. You can't give a business user access to reports while hiding lakehouses or notebooks. If they're in the workspace, they see everything (even if they can't edit it).

• Governance at scale becomes difficult As the number of items grows, folder organisation only goes so far. Without workspace-level boundaries, you lose the ability to enforce ownership, audit access, or delegate administration to different teams.

• Deployment coupling That single deployment pipeline is a pro until it isn't. If you need to deploy a report fix without also deploying in-progress pipeline changes, you can't. Everything moves together or nothing does.

• Exit costs Migrating from a single workspace to a split model later requires creating shortcuts, re-pointing semantic models, and potentially re-configuring row-level security. The longer you stay in this topology, the more work it is to leave.

 

Example Scenarios

• Small central BI team A team of 3–4 people responsible for all analytics in a department. They build the pipelines, they build the models, they build the reports. No separation between "engineers" and "analysts" because they're the same people. Access control isn't a concern because everyone needs to see everything anyway.

• Proof of concept or pilot You're exploring Fabric for the first time, or proving out a use case before committing to a broader rollout. Speed matters more than governance. You want to learn how the pieces fit together without getting bogged down in workspace design.

• Single-domain, single-consumer scenario One team produces data, one team consumes it, and they trust each other completely. There's no political or organisational reason to separate them. The overhead of multiple workspaces would add complexity without adding value.

• Temporary project workspace A time-boxed initiative (migration, one-off analysis, hackathon) where you need a sandbox to work fast. Governance and long-term maintainability aren't priorities because the workspace will be decommissioned when the project ends.

 

When This Topology Breaks Down

• You have distinct teams who shouldn't see each other's work (security/compliance requirement)

• Report consumers and data engineers have fundamentally different access needs

• You need to charge back capacity costs to different cost centres

• You want to deploy reports and pipelines on independent release cycles

• The workspace item count grows past the point where folders provide meaningful organisation (roughly 50+ items)

When you hit these limits, Split Topology is the natural next step.

 

Considerations

​

Folder naming conventions matter Folders are your only organisational lever here. Establish a clear convention early (e.g. 01_Ingestion, 02_Bronze, 03_Silver, 04_Gold, 05_Semantic, 06_Reports) and enforce it. Inconsistent folder usage erodes the only structure you have.

​

Plan your exit path Even if this topology fits today, document how you'd migrate to Split or Hub and Spoke if requirements change. Knowing the exit path reduces the cost of the decision.

 

Monitor capacity closely Without workload isolation, capacity contention is your biggest risk. Set up monitoring early so you can see when one workload is impacting another, and have a plan for what you'll do when it happens.