Microsoft Fabric Policies: Rule-Based Governance

Navy Solv Systems title card reading 'Policies in Microsoft Fabric' with a checklist with shield badge motif.

In Short: Microsoft Fabric Policies Turn On/Off Switches Into Rules

Until now, most governance decisions in Microsoft Fabric came down to a tenant switch: a capability is on for everyone, on for some security groups, or off. Microsoft Fabric policies, announced in preview at FabCon Europe on 29-30 September 2026, add a finer tool. An administrator writes allow rules that combine conditions - who the user is, which workspace they are in, what item type they are creating, which sensitivity label is on the data - and Fabric checks those rules at the moment someone tries the action.

It is the difference between "Dataflow Gen2 is enabled" and "only the data engineering group may create Dataflow Gen2 items in the two production workspaces". The second is what most organisations meant all along.

This post covers what Microsoft has documented, the one behaviour that will catch people out, and how we would roll it out.

What Microsoft Fabric Policies Cover Today

Microsoft Learn documents three policy types in the preview:

Allow item creation - capacity scope. Controls which item types users can create in workspaces on a given capacity. Conditions can use item type, security group and workspace. Default: all item types allowed.
Allow workspace settings editing - tenant scope. Controls which workspace admins can change security-sensitive settings, currently customer-managed keys (Encryption) and outbound networking. Default: editing allowed. A tenant setting still wins - allowing someone to edit a setting does not switch on a capability the tenant has disabled.
Allow external data sharing - tenant scope. Controls who can create external data shares, from which workspaces, for items with which sensitivity labels, and to which recipient email domains. When no active policy manages it, Fabric falls back to the existing tenant setting.

One status note. The 30 September "Build, deploy, and govern Microsoft Fabric at scale" announcement said item creation and workspace security were supported at launch, with external data sharing "coming soon". The Learn pages and the September feature summary already describe the external sharing policy in full. Treat it as documented but confirm it appears in your own tenant before you build a process around it.

Everything here is preview. That matters for production governance: preview features can change, and Microsoft's support terms for them differ.

How the Rules Work

Each policy lives in a policy set, which is a normal Fabric item created from New item in a workspace assigned to a capacity. You pick tenant or capacity scope when you create it, and you cannot change it afterwards. The Policies tenant setting has to be enabled first, and it can be limited to specific security groups.

Inside a policy, each rule is a set of conditions with an Allow effect. Microsoft Learn describes the logic plainly:

Conditions within a rule combine with AND - every one must match
Separate rules combine with OR - matching any one rule is enough
Values within a condition use "is any of" or "is none of"
An omitted condition matches everything

Limits from Learn: up to 100 rules in a tenant-scoped policy, up to 50 rules in a capacity-scoped one, and up to 50 values in a condition. Only one policy set can be active per scope at a time.

Activation is deliberate. Anyone with the right workspace role can create and edit a policy set, but nothing is enforced until a Fabric administrator (tenant scope) or capacity administrator (capacity scope) activates it. Microsoft says changes take effect within 15 minutes. Active policies then show in the Policies center on the Govern tab of the OneLake catalog, and enforcement decisions are recorded in the Fabric audit logs.

Microsoft Learn also says policies are included with your Fabric licence at no extra charge and do not consume capacity units.

The Allow-List Trap

This is the behaviour that will cause the first support tickets.

A policy starts at its system default - for item creation, everything is allowed. The moment you switch it to Advanced and add a rule, it becomes an allow list. Anything that does not match at least one rule is denied.

Microsoft's own example makes the point. A capacity admin wants only the DataflowGen2-Creators group to create Dataflow Gen2 items in two production workspaces. Rule 1 says exactly that. On its own, Rule 1 would block every other item creation across the whole capacity, so Rule 2 is needed: any user, any item type, in workspaces that are none of those two.

The practical rule: write the "everything else carries on as normal" rule first, then add the restrictive one. Learn's guidance is to test with users who are both inside and outside the configured groups before activation, and that is not optional. Policy rules sit on top of workspace roles; they never grant access a user did not already have, but they can remove abilities people rely on.

Where Policies Fit Alongside What You Already Have

Policies do not replace the rest of the Fabric security model. Workspace roles still decide who can work in a workspace, item permissions and OneLake security still decide who can read data, and Purview still classifies it. Policies govern actions - create this, share that, change this setting.

They do pair well with three things we already recommend:

Domains. If you have organised workspaces into domains, domain boundaries tell you where rules should differ. Note that Learn says domain and workspace admin scopes are not currently available, so rules target workspaces and capacities, not domains directly.
Workspace conventions. Rules reference workspace IDs, so the workspace governance habits of stable dev, test and prod workspaces per domain make policies far easier to write and maintain.
Sensitivity labels. The external sharing policy can key off labels, which only works if labels are applied consistently. Our guide to Purview governance in Fabric covers getting labels in place.

For AI agents and apps reading data rather than people creating items, see giving AI agents secure access to OneLake, which covers the other new controls announced alongside policies.

Two Constraints to Check First

Region. Microsoft Learn currently lists West Europe, North Europe and West US as capacity regions where Fabric policies are not supported. Many UK and European estates run capacities in West Europe or North Europe, so check your capacity regions before you design anything.

Git and activation. Policy sets are Fabric items, with REST APIs and Git integration for definitions, so rules can be versioned and promoted. But Learn is explicit that you cannot activate a policy through Git. Activation stays a named admin action, which is arguably what you want for governance.

How We Would Roll It Out

Start with one capacity and the item creation policy. It is capacity-scoped, so the blast radius is contained, and the default is allow-all.
Store policy sets in a locked-down admin workspace, as Microsoft recommends, with clear names that say the scope and purpose.
Write the catch-all rule first, then the restriction, then test with members and non-members of each group.
Activate, wait the 15 minutes, check the audit logs before telling anyone it is live.
Write down what each rule is for. Rules reference group and workspace IDs, so a rule without a description becomes unreadable in six months. That register belongs in your data governance framework.

Workspace settings and external sharing policies come next, once the tenant-level behaviour is understood and, for external sharing, once it appears in your tenant.

Where Solv Systems Comes In

We review Fabric tenants against what policies can now express: which tenant switches are really "only these people, only here", which capacities need item creation rules, and whether your regions support the feature yet. Then we write, test and document the rules so the first activation does not block a finance team on a Monday morning. Our Microsoft data governance service covers this end to end.

Sources and Further Reading

Frequently asked

A preview governance feature that lets administrators allow specific actions only under specific conditions - for example, only one security group may create Dataflow Gen2 items in production workspaces. Each policy is stored in a policy set item in a workspace and enforced only after a Fabric administrator or capacity administrator activates it.

Microsoft Learn documents three: Allow item creation (capacity scope), Allow workspace settings editing (tenant scope, covering customer-managed keys and outbound networking settings) and Allow external data sharing (tenant scope). Microsoft's 30 September 2026 announcement said external data sharing was coming soon, while Learn already documents it, so check it appears in your tenant before planning around it.

Once a policy is in Advanced mode with rules, it behaves as an allow list: an action is permitted only if it matches at least one rule, and anything that matches no rule is denied. A rule that allows only notebooks and lakehouses therefore blocks every other item type unless another rule allows it.

Microsoft Learn says Fabric policies are included with your Fabric licence at no extra charge and do not consume capacity units. The policy set item does need to live in a workspace assigned to a Fabric capacity.

No. Microsoft Learn currently lists West Europe, North Europe and West US as capacity regions where Fabric policies are not supported. Check your capacity regions before designing around them.

Yes for definitions, no for activation. Policy sets are Fabric items with REST APIs and Git integration, so rules can be versioned and deployed like other items, but Microsoft Learn states you cannot activate a policy through Git. Activation remains an explicit admin step.