Everything lives in a single workspace. You separate concerns with folders: one for ingestion pipelines, one for lakehouses, one for semantic models, one for reports. Everyone with workspace access can see everything, though you can still control edit versus view permissions at the workspace level.
One workspace
- Ingestion
- Lakehouse
- Semantic models
- Reports
Why teams start here
This is the fastest way to get building. There are no shortcuts to manage, no cross-workspace dependencies to think through, and no duplicated security setup. That simplicity has real limits, though: you can't isolate capacity consumption between teams, you can't give one group access to reports without exposing the underlying engineering assets, and folder-level permissions don't exist in Fabric today.
Pros and cons
Pros
- Fast to start. No architectural decisions to agonise over. Create one workspace and start building.
- Simple security model. One set of workspace roles (Admin, Member, Contributor, Viewer) and you're done.
- No shortcut management. Items reference each other directly, with no cross-workspace shortcuts to maintain.
- Easy discoverability. For small teams, everything visible in one place cuts confusion.
- Single deployment pipeline. One workspace, one pipeline, everything moves Dev to Test to Prod together.
Cons
- No capacity isolation. A heavy pipeline can starve report refreshes, or the reverse, with no lever to separate them.
- Coarse access control. Workspace roles are all-or-nothing. You can't hide lakehouses from a business user while keeping reports visible.
- Governance gets hard at scale. Folder organisation only goes so far without workspace-level boundaries to enforce ownership or delegate administration.
- Deployment coupling. You can't deploy a report fix without also deploying in-progress pipeline changes.
- Rising exit costs. Migrating to a split model later means creating shortcuts, re-pointing semantic models, and possibly re-configuring row-level security.
Where this fits
- Small central BI team. Three or four people who build the pipelines, the models, and the reports themselves. No engineer/analyst split, and no access control concern because everyone needs to see everything anyway.
- Proof of concept or pilot. You're exploring Fabric, or proving a use case before a broader rollout. Speed matters more than governance.
- Temporary project workspace. A time-boxed migration, analysis, or hackathon that needs a fast sandbox and will be decommissioned when the project ends.
When this breaks down
- You have distinct teams who shouldn't see each other's work
- Report consumers and data engineers need fundamentally different access
- You need to charge back capacity costs to different cost centres
- You want to deploy reports and pipelines on independent release cycles
- Item count grows past the point where folders provide meaningful organisation, roughly 50 or more items
When you hit these limits, Split topology is the natural next step.
Considerations
- Folder naming conventions matter. Folders are your only organisational lever. Set a clear convention early (01_Ingestion, 02_Bronze, 03_Silver, 04_Gold, 05_Semantic, 06_Reports) and enforce it.
- Plan your exit path. Document how you'd migrate to Split or Hub and Spoke before you need to, so the decision doesn't cost more later.
- Monitor capacity closely. Without workload isolation, capacity contention is your biggest risk. Set up monitoring early.