Spinning up a Microsoft Fabric workspace takes 30 seconds.
Untangling a badly designed one takes 30 days.
As a Data Architect building Modern Data Platforms on Microsoft Fabric, I keep seeing the same pattern. Teams click "Create workspace," start loading data, and only start thinking about governance, lifecycle, and capacity once the bill starts hurting or the auditors come knocking.
Here's the catch — most of those problems are creation-time decisions. Once a workspace has lakehouses, notebooks, pipelines, and reports tied to it, retrofitting is painful and expensive.
So before I let any new Fabric workspace get provisioned, I walk through 9 considerations:
- Capacity & Region: which F-SKU, which region, aligned to where source data actually lives
- Workspace Identity: managed identity over service principals, from day one
- Domain Assignment: for OneLake catalog discoverability and data mesh alignment
- Access Model: Entra ID groups mapped to workspace roles, never individuals
- Git Integration: Azure DevOps or GitHub linkage decided up front, not bolted on later
- Deployment Pipelines: dev / test / prod separation defined before any items exist
- Network Isolation: private endpoints and trusted workspace access for ADLS
- Naming & Tagging: a convention that supports chargeback via the Capacity Metrics app
- Sensitivity & Compliance: Purview integration and DLP labels applied at creation, not retroactively
The pattern I keep coming back to: workspace design is architecture, not admin.
Treat it that way, document the decisions in an ADR (Architecture Decision Record), and you'll save your team a painful migration twelve months from now.
What's the one decision you wish you'd made before creating your first Fabric workspace? Curious to hear the lessons.
#MicrosoftFabric #DataArchitecture #Azure #DataEngineering #OneLake