What it does

Data policies sort connectors into three groups — Business, Non-Business and Blocked — and stop apps and flows from combining connectors across groups. Dataverse sits in the middle of this as a connector that can't be blocked, which shapes every policy design you'll ever write.

Key facts

• Connectors in the same group can share data. Connectors in different groups can't. Blocked means the connector can't be used at all.
• Dataverse and Dataverse (legacy) are non-blockable. They're the only premium connectors that can't be blocked, because Dataverse is part of the base platform. You can only classify them Business or Non-Business.
• The rest of the non-blockable list covers core platform connectors — Approvals, Notifications, Power Apps Notifications, Copilot Studio — and Microsoft Enterprise Plan standard connectors including SharePoint, Microsoft 365 Outlook, Teams, OneDrive for Business and Power BI.
• Whichever group Dataverse goes into effectively defines what "Business" means in that tenant, because almost every model-driven app and most flows touch it.
• New connectors are automatically placed in the policy's designated default group. Microsoft's guidance is to keep that as Non-Business so new connectors arrive restricted rather than trusted.
• If Blocked is the default group and Microsoft adds a new non-blockable connector, it lands in Non-Business instead.
• HTTP, HTTP Webhook and When an HTTP request is received are classifiable. Child flows have an internal dependency on the HTTP connector, so blocking or misgrouping HTTP breaks child flows in that environment or tenant.
• The Content Conversion connector isn't available for classification at all.
• Advanced connector policies (ACP) work the other way round: a strict allowlist where everything is blocked unless explicitly allowed, and ACP can restrict the connectors that classic policies can't block — including Dataverse. ACP currently covers certified connectors only; custom connectors, HTTP connectors and virtual connectors aren't in scope.
• Custom connectors are classified per environment at environment level, or by host URL pattern at tenant level with an ordered allow/deny list ending in a * rule that defaults to Ignore.
• Enforcement is a background cascade: policy saved, pushed to environments, resources evaluated, violating apps and flows moved to suspended or quarantined, connections disabled if the whole connector is blocked. Usually within an hour, up to 24 hours in extreme cases.

When to use / skip

Every tenant needs at least one data policy, and the interesting design question is always where Dataverse sits. Put it in Business alongside SharePoint, Teams and Outlook, block or push everything consumer-facing into Non-Business, and you have a defensible default that doesn't break model-driven apps. Where it gets subtle is environments containing genuinely sensitive Dataverse data — classic policies can't stop a maker connecting Dataverse to anything else in the same group, only to things in a different group. If you need to actually restrict what Dataverse can be combined with, that's an environment-level policy with a narrow Business group, or ACP.

Configuration decisions

• Which group Dataverse goes in, which is really the decision about what your Business group means.
• Tenant-level baseline policy plus environment-level exceptions, versus per-environment policies throughout.
• Where HTTP connectors sit, and whether child flows are needed in that environment at all — the documented pattern is to keep HTTP out of shared environments and give makers a dedicated environment with a restricted maker list.
• Whether ACP is adopted for the environments where the allowlist model is worth the operational overhead.
• The custom connector strategy: classify by URL pattern at tenant level, or leave the * rule as Ignore and handle it per environment.

Gotchas

• Clients ask to block the Dataverse connector and you can't, through classic policies. Explain ACP rather than promising something the policy UI won't do.
• Moving Dataverse between groups on an existing policy suspends every app and flow that combined it with something now in a different group. Model the blast radius before saving.
• Blocking or misgrouping HTTP silently breaks child flows, and the error doesn't say "HTTP connector policy".
• A connector already sitting in Blocked from an older policy stays there until you edit the policy, at which point you can't save until you move it out. That surfaces at the worst moment.
• The policy view in PowerShell and the Power Platform for Admins connector only shows explicitly classified connectors and can carry stale references — the admin centre shows everything. Two tools, two answers.
• Enforcement isn't instantaneous. Someone will change a policy, test immediately, conclude it didn't work, and change it back.

Consultant notes

• Draw the Business group on a whiteboard with Dataverse in the middle before touching the admin centre. The policy is easy; the classification argument is the engagement.
• Set expectations that data policies restrict connector combinations, not row-level access. They're not a substitute for the Dataverse security model and clients conflate the two constantly.
• Keep the default group as Non-Business and say why in the governance document, because someone will eventually propose Blocked as "more secure" and it isn't — it just moves new non-blockable connectors to Non-Business anyway.
• If a client is heading towards ACP, flag the current gaps — custom connectors, HTTP connectors, virtual connectors — so they don't retire their classic policies too early.

---

Worth another look as advanced connector policies pick up custom and HTTP connector support.