“Do we really need another workspace?”
If you’ve built anything meaningful in Microsoft Fabric, you’ve heard some version of that question. It usually comes wrapped in a familiar anxiety: workspace sprawl. Too many containers. Too much to govern. Too hard to manage.
Here’s the reframing that matters: workspace count is rarely the risk. The real risk is stale workspaces and stale data—the forgotten corners of your tenant where ownership is unclear, permissions linger, and the platform quietly accumulates operational and compliance debt.
In this post I’ll walk through why “workspace sprawl” is a false fear, why workspaces naturally form clusters (and why good development multiplies them), and how intentional permissioning in Microsoft Entra and Fabric keeps management from becoming a linear slog—especially once you introduce automation and tooling. Along the way, I’ll ground the point in the real mechanics of Microsoft Fabric rather than vibes.
Why “sprawl” is the wrong mental model for Fabric workspaces
A Fabric workspace isn’t a precious, scarce object. It’s a collaboration and packaging boundary: a place to build collections of items like lakehouses, warehouses, and reports, and to structure work with things like task flows.
More importantly, Fabric workspaces sit on top of OneLake and act as securable containers—a deliberate design choice that lets you segment work in a way that maps to how organizations actually operate.
When leaders fear “workspace sprawl,” what they often mean is:
- “We’re going to lose control.”
- “Security reviews will become impossible.”
- “Support effort will grow linearly with the number of workspaces.”
The problem is that those fears are not solved by having fewer workspaces. They’re solved by having clearer ownership, lifecycle management, and permissioning that scales.
Workspaces don’t multiply randomly—they multiply in clusters
Workspaces “sprawl” on a whiteboard. In real organizations, they cluster.
A cluster might be a business domain, a product line, a department, or a portfolio of related data products. Fabric literallysupports this idea through Domains, where you organize your platform by assigning workspaces to a domain (and subdomains), associating the items in those workspaces with that business context.
Domains matter here for two reasons:
- They acknowledge what’s already true: workspaces tend to form meaningful groupings.
- They give you a way to manage those groupings as a unit, not as a pile of one-offs.
And this is where good development practices “cause” workspace growth—because healthy platforms create moreintentional boundaries:
- Environment separation (dev/test/prod, or similar patterns)
- Team ownership boundaries (data engineering vs BI vs operational analytics)
- Project and product boundaries (each product has its own lineage, cadence, and stakeholders)
- Experimentation sandboxes (innovation without contaminating production)
That multiplication isn’t a failure. It’s often a sign that you’re doing analytics engineering instead of building a single fragile monolith.
The real threat: stale workspaces and stale data
If workspace sprawl is the fear, staleness is the risk.
A stale workspace is one that is no longer used (such as an old branch that hasn’t been deleted, or a tool that’s not being used) or where the platform can no longer answer basic questions with confidence:
- Who owns this?
- Who should still have access?
- Is the data still being refreshed and used?
- If something breaks, who gets notified?
Fabric even provides practical mechanics you can use to support ownership, like the workspace contact list used for notifications about workspace activity and issues.
When those ownership signals are missing or outdated, your governance problems start compounding:
- Security drift: permissions granted for a project that ended 18 months ago don’t automatically expire.
- Operational drag: failed refreshes, broken dependencies, and “mystery datasets” take time to triage.
- Discovery noise: users can’t find the right thing because there’s too much old thing.
- Compliance exposure: retention and access expectations become guesswork instead of policy.
This is where data governance becomes real and moves beyond just creating and agreeing on a data dictionary. Not as a committee. As a set of habits that prevent your tenant from turning into an archaeological site.
Staleness is measurable (and that’s good news)
The fastest way to shift the conversation is to stop debating “too many workspaces” and start tracking staleness indicators.
For example, Microsoft’s guidance on the Power BI activity log focuses on programmatic retrieval of activity (including workspace-scoped activity), with up to four weeks of history available via the Power BI Management PowerShell module.
That’s not the only signal you can use, but it’s emblematic of the broader point: the platform emits the telemetry you need—you just have to choose to treat staleness as a first-class problem.
Permissioning that doesn’t scale linearly
This is the part that usually changes the mood in the room: management does not have to become linear with the number of workspaces.
If your operational model is “hand-assign individual people to individual workspaces,” then yes—more workspaces means more pain.
But Fabric’s model is built to scale when you use it intentionally.
Use Entra groups as the unit of management
Fabric workspace roles can be assigned not just to individuals, but also to security groups, Microsoft 365 groups, and distribution lists. Membership inheritance and nesting allow users to receive the highest permission granted by their group memberships.
That means you should design access around stable group concepts like:
Domain-Sales-Workspace-AdminsDomain-Sales-ContributorsDomain-Sales-ViewersProduct-X-Developers
Then you assign the groups to workspaces, not the people.
This is also a practical response to scale limits. Fabric has a documented limit of 1,000 users or groups assigned to workspace roles, but that limit doesn’t apply to the number of users inside a group—so group-based assignment is the obvious scaling pattern.
This is #EntraID doing what it’s supposed to do: centralize identity lifecycle, approvals, and membership hygiene—so Fabric doesn’t become your identity management system.
Keep workspace roles broad, then use item permissions for exceptions
Fabric’s permission model is explicit: workspace roles control access to the workspace and apply to all items within it; item permissions are for controlling access to individual items when needed.
Practically, that means you don’t need to create a whole new workspace just to handle one special-case artifact. Use workspaces for product boundaries, and item permissions for the exceptions.
Use privileged access patterns for admin responsibilities
Fabric administration itself is governed through dedicated admin roles (such as Fabric administrator), which provide access to the Fabric admin portal and tenant-level controls without requiring full Microsoft 365 admin rights.
And on the Entra side, role assignments can be managed via role-assignable groups, which simplifies auditing and keeps admin assignment consistent.
If you need just-in-time elevation, Microsoft Entra Privileged Identity Management (PIM) exists specifically to manage, control, and monitor access to important resources.
Make access lifecycle explicit with access packages
Stale access is often the root cause of stale workspace risk.
Microsoft Entra entitlement management introduces access packages, bundling the resources and access an identity needs to do a job—paired with policies for request, approval, and lifecycle.
When you combine access packages with group-based workspace role assignments, you get a clean pattern:
- Access package grants group membership
- Group membership grants workspace role
- Expiration/review revokes membership automatically
- Workspace access doesn’t silently outlive the project
That’s how you stop governance from becoming a manual clean-up exercise.
Tools make 300 workspaces feel manageable
Once you stop thinking in individual-workspace clicks, the obvious next step is tooling.
Fabric has multiple governance surfaces designed for scale:
- The Fabric admin portal includes tenant settings, audit logs, domains, and tags—central controls for how your organization uses Fabric.
- Fabric includes REST APIs designed to automate Fabric processes, including workspace operations.
- The Fabric List Workspaces REST API returns the workspaces a principal can access and supports service principals and managed identities—meaning automation doesn’t have to run as a human.
- For infrastructure-as-code approaches, there is an open-source Terraform provider for Microsoft Fabric, intended to manage Fabric resources in a repeatable way.
You don’t need a giant custom platform on day one. Even a lightweight “workspace inventory + staleness report” changes the conversation immediately. It turns fear (“we have too many workspaces”) into operations (“these 47 are inactive, these 12 have no owner group, these 9 have refresh failures”).
And that’s the point: workspaces can grow exponentially without your management effort doing the same—if your unit of management is groups, domains, and automation rather than individual workspace edits.
Bringing it all together
Workspace sprawl is a comforting story because it sounds simple: “less stuff = less risk.”
But Fabric wasn’t built for that story. It was built for a world where teams build many data products, in many workspaces, across many domains—and where those boundaries are a feature, not a bug.
The real risk isn’t that you’ll have 40 workspaces instead of 12. The real risk is that you’ll have 40 workspaces and no reliable way to know which ones are alive, owned, and trustworthy.
If you want to get ahead of it, don’t start by restricting workspace creation. Start by designing:
- Ownership that’s visible and durable
- Group-based access that scales
- Lifecycle and review that prevent staleness
- Tooling that keeps governance proportional to complexity
Workspaces will cluster. Good development will multiply those clusters. That’s not bad. That’s your platform growing up.
