What it does

Data policies sort connectors into Business, Non-business and Blocked groups and stop an app combining connectors from two different groups. For apps specifically, the enforcement lands in two places: the maker can't save in Studio, and the connection the published app depends on gets disabled.

Key facts

• A new policy is created with every connector in Non-business by default. You move things into Business or Blocked from there.
• Design-time enforcement blocks the save in Power Apps Studio with a "blocked by policy" error. Runtime enforcement disables the connection, so the published app throws a broken-connection error instead.
• When a policy changes, the platform cascades it to every environment, then each app is re-evaluated. Violating apps go into a suspended or quarantine state and stop working for end users.
• Documented worst-case latency for full enforcement is 24 hours. Most tenants see it inside an hour.
• Blocking a whole connector disables the connections themselves. Users then can't repair the connection, because the design-time experience blocks that too — a dead end that looks like a bug to the user.
• You can't block Dataverse, Approvals, Notifications, Power Apps Notifications (v1 and v2), or the Microsoft Enterprise Plan standard connectors (SharePoint, Microsoft 365 Outlook, Teams, OneDrive for Business, Excel Online (Business), Power BI and friends) through classic data policies. They can only be Business or Non-business.
• Advanced connector policies (ACP) invert the model: a strict allowlist where everything is blocked unless explicitly allowed. ACP covers certified connectors and MCP connectors only — custom connectors and HTTP are still classic-policy territory.
• On a managed environment, ACP can block connectors that classic policies can't touch, including the nonblockable list. On a non-managed environment those stay nonblockable.

When to use / skip

Not a choice you get to make — every tenant has a default policy and most enterprises have several stacked on top. The question you're actually answering on a project is which policy applies to the environment you're building in, and whether the connectors in your design are all in the same group. Classic policies are still the pragmatic default for most clients. ACP is worth pushing for where the client has a genuinely regulated environment and someone willing to own an allowlist, because a default-deny posture that nobody maintains becomes a ticket queue very quickly.

Configuration decisions

• Whether app governance is done through classic data policies, ACP in mixed mode, or ACP-only — and if ACP, whether it's applied per environment or through environment groups.
• Where the custom connectors and HTTP sit, since those two are the exfiltration route and ACP doesn't cover them yet.
• Whether to use connector endpoint filtering to pin apps to specific SQL servers or SharePoint sites, accepting that the policy becomes something only its author understands.
• Whether the default group for new connectors stays Non-business. Microsoft's guidance is to leave it there and promote deliberately; setting the default to Blocked catches new nonblockable connectors and silently reclassifies them anyway.
• How you tell makers a policy is changing, given the evaluation job will suspend live apps without warning them.

Gotchas

• Design-time enforcement for ACP is rolling out in portal order: Power Automate first, then Copilot Studio, then Power Apps. Until it reaches the Power Apps maker portal, ACP is runtime-only for apps — makers can build something that dies on publish.
• Removing an ACP rule from an environment group doesn't remove it from the environments that inherited it. Same when you pull an environment out of a group. That's deliberate, to avoid an enforcement gap, but it surprises admins who expect the group to be authoritative.
• The app's licence designation doesn't help you here. An app whose connectors all sit in Business can still break because a flow it calls uses a connector that doesn't.
• Blocking the connector kills the connection, not just the app. Expect support tickets phrased as "my app broke" rather than "the policy changed".

Consultant notes

• Get the connector inventory for the environment before you design. The Power Platform inventory connector column (preview) tells you which apps use which connectors, which used to be a CoE Starter Kit job.
• Ask specifically which environments the policy covers. "We have DLP" usually means the default environment and a policy nobody has reviewed since 2022.
• Warn the security team that saving a policy is a production event for apps, not just flows. Recommend a maintenance window.
• If the client is being sold ACP, check whether their custom connectors matter. If they do, they're running both policy systems for the foreseeable future and should plan for mixed mode rather than a clean cutover.

---

Worth revisiting once design-time ACP enforcement actually lands in the Power Apps maker portal, or when custom connector support arrives.