Using Allow workspace settings editing policy in Fabric (Preview)

Your teams are ready to build. They know their data, understand their business, and need the freedom to manage the workspaces where ideas become solutions. As adoption grows, that freedom becomes even more valuable. So does the ability to protect the settings that matter most.

A workspace admin role brings broad responsibility. But owning an analytics workspace shouldn't mean every administrator also needs authority over its encryption and networking. Organizations need a more precise way to share responsibility, without pulling everyday workspace management back into a central team's queue.

At FabCon Barcelona, we introduced the Allow workspace settings editing policy, part of Microsoft Fabric policies, currently in preview. We're excited to give organizations finer control over sensitive workspace changes while keeping teams in charge of their day-to-day work.

Now, you can delegate workspace ownership with clearer boundaries around who can change what, and where.

Figure: Animated GIF - Configure and enforce network security through the Allow workspace settings editing policy.

Put the right decisions in the right hands 

Fabric administrators can centrally define which workspace admins may edit supported settings, using conditions based on Microsoft Entra security-group membership, workspace, and setting type. The same organization can reserve some changes for a security team and delegate others to approved platform teams. 

We're starting with security-sensitive controls: customer-managed key encryption and outbound networking. Workspace admins keep their role and can continue managing unrelated workspace settings. An allow rule adds no new workspace privileges; users still need the workspace admin role to make these changes. 

That precision opens up practical ways to give teams more autonomy. Below are a few examples. 

Putting this to practice – Real scenarios from our customers 

Delegate workspace administration while retaining control of encryption 

Consider a bank that wants business teams to administer their own analytics workspaces. Its security team is reluctant to expand the workspace admin role because those users could also change customer-managed key settings. 

The Fabric administrator uses the policy to allow encryption edits only for workspace admins in an approved security group. The bank can then give more business users the workspace admin role without authorizing them to change that encryption configuration. Business teams handle everyday administration; the security team retains control of customer-managed key settings. 

Give development teams room to experiment 

A development sandbox and a production workspace serve different purposes. They shouldn't automatically need the same operating model. 

For example, an organization can allow workspace admins to edit outbound networking in designated development workspaces while reserving those changes in designated production workspaces for an approved platform group. Separate allow rules make those boundaries explicit. 

Developers gain flexibility where experimentation is expected. Production teams retain tighter control where a change can affect business-critical work. Administrators can reflect those differences in policy rather than impose the same restrictions everywhere.

Bring networking decisions closer to the teams delivering solutions 

As Fabric adoption expands across business units, one central platform team can become the default destination for every networking request. Approved regional or business-unit platform teams may already have the expertise to take on some of that work. 

Fabric administrators can authorize those teams to edit outbound networking settings in specific workspaces, provided the people making the changes are also workspace admins.  

This creates a path to distribute administration as the organization grows. Qualified teams can handle changes within their assigned workspaces, while central administrators define and maintain the boundaries.

Make the boundaries part of the workflow 

A governance decision has more value when the platform enforces it. Fabric evaluates the policy in the portal and through APIs, and records policy enforcement decisions in audit logs. Administrators can manage active policies centrally in the OneLake catalog's Policies center. 

The policy controls who can edit, giving organizations a way to enforce responsibility for future changes alongside their existing security and operational processes. 

Get started 

Choose a concrete scenario: reserve encryption changes for security specialists, or give an approved platform team control over outbound networking in selected workspaces. Identify the relevant workspace admins and security groups, then define the allow rules. 

Advanced mode uses an allow list: governed edits that match no rule are blocked. Plan every scenario you want to preserve across the tenant, including settings and workspaces outside your initial focus. Note that allowing encryption edits alone, for example, can block managed private endpoints edits unless another rule allows them. 

When your rules are ready, create and activate a tenant-scoped policy set. Validate both allowed and blocked scenarios with test accounts, and review the enforcement results before broader adoption. 

As more teams build with Fabric, governance needs to support that growth. Give people the freedom to own their workspaces, with sensitive security changes in the hands of the right specialists. That's how you make room for the next team and its next idea. 

Learn more about Allow workspace settings policy. 

We’re happy to hear any feedback you have about Fabric policies. To let us know what’s on your mind, fill out this form so we can better understand how policies are impacting your Fabric usage, what is working well, and what new policy capabilities would be most valuable.