Data loss prevention (DLP) policies in Power Platform

A maker building a Power Automate flow can connect to hundreds of services — Microsoft and third-party. Without governance, a flow could read from SharePoint (business data) and send to Twitter (public-facing) — accidentally exposing sensitive information. Data Loss Prevention (DLP) policies in Power Platform classify connectors into groups and restrict their combination within a single flow or app. Designed well, DLP prevents data leakage with minimal friction; designed poorly, it blocks legitimate work and drives shadow IT.

The policy model. Each policy:

• Scopes environments — applies to specific environments or tenant-wide.
• Classifies each connector into one of three groups:
  • Business — approved for business data.
  • Non-Business — not approved; commonly limited to specific use cases.
  • Blocked — cannot be used at all.

A flow or app can use connectors only within one group, not across groups. So a flow with SharePoint (Business) cannot also use Twitter (Non-Business).

The three groups in detail.

• Business — Microsoft 365 connectors (SharePoint, Outlook, Teams), Dataverse, approved enterprise connectors (Salesforce, ServiceNow if approved by the org).
• Non-Business — connectors approved for non-sensitive use (RSS, weather, Twitter for marketing).
• Blocked — connectors not allowed at all (third-party file-sharing services with weak controls, untrusted endpoints).

A connector defaults to one group; admins classify it explicitly.

Custom connectors. Connectors built in-house land in their own classification:

• Default group — typically Business since they're built for business needs.
• Per-connector classification — admins can override.

A bring-your-own connector that hits an unapproved API can be blocked.

Tenant-wide vs environment-scoped.

• Tenant-wide policy — applies everywhere; default protection.
• Environment policy — overrides tenant policy for a specific environment.

Pattern: strict tenant policy by default; relaxed policy for sandbox / dev environments where experimentation is needed.

Exemptions. Critical for usability:

• Specific apps and flows can be exempted from a policy.
• Service accounts can have different policies.
• Admin override for specific business needs.

Without exemption mechanism, every edge case becomes a policy battle.

HTTP connector specifics. The generic HTTP connector is powerful and dangerous. DLP can:

• Block entirely.
• Allow with URL pattern restrictions — only HTTPS calls to specific domains.
• Allow with authentication restrictions — only OAuth.

Most regulated environments block generic HTTP outright and require specific connectors.

Policy enforcement.

• At save time — flow or app fails to save if it violates policy.
• At runtime — running an existing flow violating policy halts.
• Existing flows — when policy is tightened, existing flows that violate are suspended.

The runtime suspension is operationally significant — sudden flow failures need maker notification and resolution path.

Maker experience.

• Connector picker shows which connectors are available in the current environment.
• Blocked connectors visible but greyed out with explanation.
• Policy violation message explains why a combination is rejected.

Clear messaging reduces maker frustration; cryptic blocks generate support tickets.

Common policy patterns.

• Strict tenant default + relaxed dev environments.
• Per-business-unit policies — different BUs have different acceptable use.
• Per-data-classification policies — environments handling sensitive data have stricter policies.
• Layered policies — multiple policies with priority order.

Reporting.

• Policy adherence — which flows/apps are compliant.
• Violation attempts — what makers tried to do that was blocked.
• Exemption requests — pipeline of pending approvals.

The reporting is what makes DLP a programme, not just a config. Admins look at violation attempts to understand legitimate maker needs and adjust policy.

DLP and Connector Action Controls. A finer-grained mechanism:

• Allow a connector but block specific actions.
• "Use Twitter but not "Post Tweet."
• "Use SharePoint but not delete site."

Adds nuance but adds complexity; use when broad connector-level policy is insufficient.

Sensitivity labels and DLP. Microsoft Purview sensitivity labels integrate with Power Platform DLP:

• Labelled content can have its handling restricted.
• "Highly Confidential" labelled SharePoint files trigger additional DLP enforcement.

For organisations with mature Microsoft information protection programmes, this integration deepens DLP.

Common pitfalls.

• Default tenant policy too restrictive. Makers can't build anything; complaints flood admin.
• Default tenant policy too permissive. Data leaks happen.
• No exemption process. Makers route around DLP by building outside Power Platform.
• Policy changes without communication. Flows suddenly fail; makers blindsided.
• No reporting review. Policy stays static; doesn't adapt to evolving maker needs.
• Maker training gap. Makers don't understand DLP; mistakes compound.

Operational rhythm. Weekly violation review; monthly exemption decisions; quarterly policy refresh; annual strategic review. The policy should evolve — connectors come and go, business needs change, sensitivity classification shifts.

Strategic positioning. DLP is one of the most important governance levers in Power Platform. Without it, the maker community can technically and accidentally leak data. With it well-designed, the maker community has clear guardrails and can move fast within them. The investment in well-designed DLP pays back continuously; the cost of leakage is high. Managed Environments adds depth to DLP enforcement; for any regulated organisation, DLP is non-negotiable foundational governance.