If you wrote a DLP policy for Power Platform any time before this summer, you sorted connectors into Business, Non-Business and Blocked. That model is gone.
Advanced connector policies reached general availability on 4 June 2026. Microsoft's wording in the docs is direct about what happened. It "replaces the Business, Non-Business, and Blocked classification model in classic data policies with a strict allowlist that blocks all connectors by default." The announcement post put it more plainly still. "The old classifications are gone. There's one clear question: is this connector or action allowed vs blocked."
So the three bucket policy you have documented, and probably the starter matrix you copied it from, describes a system that no longer works the way it says.
Deny by default is a real change, not a rename
The classic model was permissive in a specific way. You sorted connectors into groups and the rule was about which groups could talk to each other. A connector nobody had classified still worked, it just sat in whatever your default group was.
Advanced connector policies invert that. From the docs: "All connectors and actions are blocked unless explicitly allowed. New connectors added to the platform are automatically blocked."
Read that second sentence again, because it's the one with teeth. Microsoft adds connectors to the platform constantly. Under the old model a new connector showed up and was usable. Under the new one it's blocked until somebody adds it to your allowlist. Your policy now needs maintenance it didn't need before, and the failure mode is a maker filing a ticket saying a connector that exists in the documentation doesn't exist for them.
One policy per environment
This one catches people who built elaborate layered policies.
"Each environment supports a maximum of one effective advanced connector policy. This policy is either directly configured on the environment or inherited from an environment group."
One. Not a stack that combines. If you had a tenant wide policy plus environment specific overrides plus a special case for the dev environment, that architecture doesn't translate. You get one effective policy per environment, either set directly or inherited from the environment group, and you need to work out which policy each environment should actually have.
Action level, which classic DLP could never do
The upgrade that makes this worth the migration pain is granularity. Classic DLP could block a connector. Advanced connector policies can allow a connector and block specific actions on it, and they give you visibility into triggers and actions individually.
That's genuinely useful. Plenty of connectors are fine to read from and dangerous to write with, and until now the only options were all or nothing. There's also control over MCP servers for agents, which matters more every month as people wire agents into things.
What breaks, and how you find out
Anything depending on a connector or an action that isn't explicitly allowlisted stops working. Flows fail. Apps lose a data source. The failure is not subtle, but the attribution is, because a flow that stopped last Tuesday for policy reasons looks a lot like a flow that stopped last Tuesday for credential reasons.
Two gaps worth knowing before you plan a migration. Custom connectors and HTTP connectors aren't yet supported by advanced connector policies. If a meaningful chunk of your estate runs on custom connectors, you can't fully express your intent yet, and you need to know that going in rather than discovering it halfway through.
How I'd approach the migration
Export your existing classic policy first, so you have the old classifications written down somewhere that isn't a portal you're about to change.
Then get the list of connectors your flows and apps actually use. Not the list you approved, the list in production. Those two are never the same and the difference is where your outages come from. Anything in use and not in your intended allowlist is a flow that breaks the moment you apply the policy.
Apply it somewhere that isn't production. Obvious, but the one policy per environment rule means you can't hedge, so you want to have made your mistakes somewhere cheap.
And rewrite whatever document describes your DLP posture. If yours still says Business and Non-Business, it's describing a model Microsoft retired in June, and anyone following it is working from something that's no longer true. Ours needed the same treatment, which is a fair indication of how quietly this change landed.
If you want help working out which flows a policy change would take down, that's most of what an environment audit turns up in the first afternoon.