Fabric Policies
Central allow-list controls for item creation, selected workspace settings and external sharing.
Creating a Fabric workspace takes seconds. Creating the right workspace—with accountable ownership, least privilege, secure connectivity, predictable capacity consumption, repeatable deployment and an eventual retirement date—is a rather different hobby.
A workspace should normally represent an owned data product, analytical solution, application, bounded operational workload, or intentionally shared platform capability.
Every workspace has accountable business and technical ownership, a support model and a reason to exist.
Identity, policy, capacity, networking, data protection and lifecycle controls are part of provisioning—not an afterthought.
Provision infrastructure through automation and promote product content through Git-backed delivery.
Not every announcement changes your workspace operating model. These do.
Central allow-list controls for item creation, selected workspace settings and external sharing.
Explicit deployment ordering plus supported pre- and post-deployment actions.
Multi-workspace telemetry, shared Eventhouse destinations and richer operational investigation.
Agents can interact with Fabric using Entra authentication and existing authorization boundaries.
Better review of workspace changes before committing them to source control.
Feature workspaces can contain only the items required for a specific branch of development.
Central administration of members and granular OneLake data roles.
DLP findings can automatically restrict access to supported Fabric items.
Agent actions inherit workspace permissions, making workspace authorization an AI security decision.
Governed operational applications can combine data, backend functions and metrics inside Fabric.
Capacity behaviour can feed operational monitoring and automation.
Supported workloads can deny outbound destinations by default and explicitly allow approved endpoints.
Workspace roles are intentionally broad. If someone needs one report, one semantic model or one table, giving access to the entire workspace is usually the wrong abstraction.
| Persona | Recommended access | Production write? | WaaS guidance |
|---|---|---|---|
| Platform administrator | Central admin capability | No standing access | Escalate only when required |
| Workspace owner | Admin via Entra group | Controlled | Keep the group small |
| Developer / engineer | Contributor in DEV | Normally no | Promote through deployment |
| Release automation | Dedicated workload identity | Yes | Only permissions required for deployment |
| Production support | Viewer + controlled elevation | Time-bound only | Use PIM-style elevation where appropriate |
| Business consumer | App / item / data permission | No | Avoid blanket workspace Viewer |
Assign workspace roles to Entra security groups. Direct user assignments should be documented exceptions.
Use apps, item permissions, SQL grants, semantic-model security and OneLake roles for consumers.
Require role-specific training and hands-on validation before granting elevated production access.
Fabric Policies are currently a Preview capability. WaaS can use policy-driven archetypes so teams receive the capabilities they need without automatically receiving everything Fabric can do.
Inbound access, outbound access, source authorization and workload identity are separate architecture decisions.
Workspace identity
OneLake security
SQL permissions
Semantic-model security
Item permissions
Automate workspace creation, capacity assignment, domain, groups, identity, settings, connections, policy baseline and Git wiring.
Typical tools:
Promote notebooks, pipelines, lakehouses, warehouses, semantic models, reports and other supported Fabric items.
Typical tools:
Deployment Plans can add explicit ordering and supported pre/post actions, but they are currently Preview and are not a rollback engine.
Tick the controls that are in place. Your browser keeps the checklist state locally.
0% WaaS ready
Map it to a domain. Separate environments. Use group-based access. Grant the smallest useful permissions. Apply explicit workload policies. Prefer identity-based connectivity. Automate provisioning. Deliver through Git. Monitor capacity and security. Recertify access. Give the workspace a retirement date.
That is Workspace as a Service.