Almanac
Microsoft/power-automatePower Platform

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

power-automate/08-governance-and-security/feature-dlp-policies.md
feature-dlp-policies.mdv1 · history
CurrentApplies to Cloud flows / Desktop flowsUpdated last monthSource Microsoft Learn ↗

What it does

A DLP policy sorts connectors into Business, Non-business and Blocked groups, and stops a flow or app combining connectors from two different groups. Microsoft now calls these data policies in the admin centre, though everyone on site still says DLP. The same mechanism classifies desktop flow modules once you turn that on.

Key facts

  • Three classifications: Business, Non-business, Blocked. Data can't move between the Business and Non-business groups within a single flow. Blocked connectors can't be used at all.
  • Policies apply at tenant scope, to selected environments, or to all environments except a named list. Environment groups are increasingly where newer "on/off" rules land.
  • Connector action control lets you allow or block individual actions and triggers within a connector rather than the whole thing. Full enforcement on triggers and internal actions landed in February 2025.
  • Endpoint filtering restricts which specific endpoints a connector may reach — SQL server names, HTTP URLs, SharePoint sites — for the connectors that support it.
  • Design-time enforcement stops the maker saving. Runtime enforcement disables the connection and fails the run.
  • Creating or changing a policy kicks off a background scan of every flow in the environment. Violating flows go to a Suspended state, with FlowSuspensionReason=CompanyDlpViolation and a suspension timestamp visible through the API and the Power Automate Management connector.
  • Enforcement is asynchronous and documented as within 24 hours, most often inside an hour. A weekly consistency job catches anything missed.
  • Cloud flows suspended in the previous seven days reactivate automatically once they no longer violate a policy. Desktop flows have their suspension removed by the same background job.
  • Advanced connector policies are the newer, more granular control. They deliberately don't support virtual connectors and never will.

When to use / skip

You'll have DLP whether you want it or not — every tenant gets a default policy and most enterprises have several. The real question is how aggressive to be. A single tenant-wide policy that blocks the obvious consumer connectors and puts everything else in Business is a defensible starting position that breaks almost nothing. Fine-grained per-environment policies with endpoint filtering are worth it when you have genuinely different risk profiles between, say, a locked-down finance environment and a sandbox. Skip the elaborate policy matrix until someone can name the data they're actually worried about, because every extra group is another support ticket.

Configuration decisions

  • Whether policies are tenant-wide with exclusions, or scoped per environment — and whether environment groups take over that job as they mature.
  • Where HTTP, custom connectors and the Dataverse connector sit, since these are the ones that carry the real exfiltration risk and the real business value.
  • Whether to use connector action control and endpoint filtering, which gives you precision at the cost of a policy that nobody but you understands.
  • Whether to turn on desktop flow modules in DLP. This is a one-way tenant setting — once enabled it can't be turned off.
  • How you communicate a policy change before you make it, given the enforcement job will suspend live flows without asking.

Gotchas

  • Turning on Show desktop flow actions in DLP policies is permanent. Read that sentence again before you flip it.
  • When desktop flow modules get added to policies, existing desktop flows are evaluated and suspended if non-compliant. Admins have broken production by editing an unrelated policy and not noticing the new modules dropped into the default group.
  • Only desktop flow modules explicitly placed in a group are enforced. Modules left out aren't governed by the default group classification, even if the default is Blocked. That's the opposite of how cloud connectors behave and it catches people.
  • Enforcement on a flow with a child flow is asynchronous, so the parent may look fine for up to a day before it suspends.
  • Blocking a whole connector disables the connections themselves, not just the flows. Users then can't repair the connection because the design-time experience blocks them too.
  • The Azure DevOps connector has a documented gap in tenant isolation enforcement — if that's your concern, data policies are the recommended mitigation.

Consultant notes

  • Get the client's DLP position documented before you design anything. Discovering mid-build that HTTP is blocked in production is a schedule problem, not a technical one.
  • Ask specifically which environments the policy covers. "We have DLP" usually means the default environment and nothing else.
  • Warn the security team that a policy change is a live production event. Recommend they change policies in a maintenance window and have the suspended-flow query ready.
  • Push for a named owner of the policy set. Policies drift when three different admins each add a connector to unblock their own project.

Worth a look when advanced connector policies mature further, or if environment group rules start absorbing what data policies do today.

Was this accurate?
Related
Tenant isolation08-governance-and-securityCommon failure patterns10-monitoring-and-troubleshootingManaged Environments08-governance-and-securityService principals and application users08-governance-and-securityMachines and machine groups02-desktop-flows-rpaApprovals overview06-approvals-and-human-in-the-loop