Power Platform DLP policies

Power Platform DLP policies govern which connectors apps and flows can combine — preventing scenarios where a Power Automate flow could, for example, read SharePoint files and post them to a personal Dropbox account. They're the foundational governance layer for any tenant doing serious Power Platform work.

How DLP policies work

Power Platform DLP isn't content-based DLP (that's Purview DLP). It's connector-based DLP — restricting how apps and flows can combine data sources.

Each connector is classified as:

• Business — appropriate for corporate data (SharePoint, Outlook, Dataverse, internal systems).
• Non-business — restricted (Twitter, Gmail, personal Dropbox, personal social media).
• Blocked — not allowed at all.

A DLP policy says: apps and flows cannot combine Business and Non-business connectors in the same artifact. A flow reading SharePoint (Business) cannot also write to Twitter (Non-business). They must be in separate groups.

Default classification

Microsoft ships default classifications for all connectors based on typical use:

• Microsoft 365 connectors — Business by default.
• Major SaaS apps (Salesforce, ServiceNow, Workday) — typically Business.
• Consumer services (Facebook, Twitter, Dropbox personal) — typically Non-business.
• Premium connectors — vary.

Admins can override per connector for specific tenant policy.

Tenant-wide vs environment-specific

DLP policies apply at two scopes:

• Tenant-wide policies — apply across all environments.
• Environment-specific policies — apply to specific environments.

Tenant-wide first, then environment-specific overrides. Typical pattern:

• Restrictive tenant-wide baseline — strong defaults for default and ungoverned environments.
• Permissive environment-specific overrides for trusted environments (production CoE environments).

Common policy patterns

Strict default

For the default environment (where citizen developers experiment):

• Microsoft 365 connectors → Business.
• Dataverse → Business.
• Major enterprise SaaS → Business.
• Consumer services → Blocked.
• HTTP / custom connectors → Blocked.

Prevents users from connecting corporate data to consumer services.

Production environments

For specific production environments where Power Apps and flows are deployed:

• All approved Business connectors → Business.
• Specific Non-business connectors allowed when justified.
• HTTP connectors allowed for explicit integration scenarios.

Developer environments

For developer environments (per-maker private environments):

• More permissive — developers need flexibility to experiment.
• HTTP and custom connectors allowed.
• Restricted on what can be built in the production environments later.

What about specific connector versions

Connectors have endpoint filtering — you can allow a connector but only to specific endpoints:

• SharePoint connector: allow only to your tenant's SharePoint, not others.
• HTTP connector: allow only to specific approved URLs.
• Custom connector: allow only when registered by specific publishers.

Granular control without blocking entire connectors.

Enforcement

DLP policies are enforced at runtime:

• Apps and flows using non-compliant combinations fail when invoked.
• Apps already deployed show errors when DLP policies tighten.
• Maker UI warns at design time about policy violations.

For tenants tightening policies, identify and update existing artefacts before enforcement.

CoE Toolkit integration

The Power Platform CoE Starter Kit provides DLP-related visibility:

• Inventory of which apps and flows use which connectors.
• DLP violation reports if policies tighten.
• Maker notification flows when their app would be blocked.

For organisations enforcing DLP at scale, the CoE Toolkit is essentially required.

Operational considerations

• Test policy changes in a non-production environment before tenant-wide rollout.
• Inventory before enforcing — know what will break.
• Communicate to makers — give them time to adjust.
• Allow exceptions through approval — specific scenarios need specific exceptions.
• Periodic review — connector landscape changes; policies should evolve.

Common pitfalls

• Policies too permissive — defeats the purpose.
• Policies too restrictive — breaks legitimate scenarios.
• No environment-specific overrides — one-size-fits-all DLP doesn't fit production scenarios.
• No communication — makers surprised by sudden policy changes.
• No inventory — surprise breakage when policy enforces.

For organisations doing serious Power Platform development, Power Platform DLP is one of the few non-optional governance controls. Without it, citizen developers will eventually connect corporate data to consumer services in ways that surprise legal / compliance. With it, the boundary is enforced automatically.