DLP Policies for Beginners

As soon as several colleagues start building their own flows in Power Automate, a blind spot quickly emerges: who connects which data to which service, and could customer data from SharePoint end up in a private Twitter feed or in a consumer connector that no one has reviewed? This is exactly what Data Loss Prevention, or DLP for short, is for. A DLP policy determines which connectors may be used at all in an environment and which connectors can be combined with one another within a flow. According to Microsoft documentation, data policies act as guardrails designed to prevent users from unintentionally exposing company data to the outside.

For IT managers at mid-sized companies, this is not a nice-to-have but the foundation of any responsible Power Automate rollout. Without a DLP policy, anyone with a license can use any available connector in any flow, including private email services, social media connectors, or unknown custom connectors. This article explains the basic concepts, shows the path to your first policy in the Power Platform Admin Center, and makes clear what actually happens in the event of a violation.

What a DLP policy actually governs

At the core of Power Apps, Power Automate, and Copilot Studio are connectors — strongly typed representations of APIs through which flows read, write, or forward data. A DLP policy assigns every connector to exactly one of three groups:

• Business: Intended for sensitive company data. Connectors in this group may only be combined with other connectors from the same group.
• Non-business: The default value for all unclassified connectors. Here too, data may only flow within its own group.
• Blocked: The connector cannot be used at all in environments to which the policy applies.

A simple example from the Microsoft documentation makes the effect tangible: if SharePoint and Salesforce are assigned to the Business group, both may exchange data within a flow. A flow that also uses Outlook.com from the Non-business group, however, is blocked, because the two groups are not allowed to share data with each other. It is precisely this principle — locking connectors into groups instead of monitoring individual data flows — that makes DLP policies so effective and, at the same time, so easy to understand.

Design time and runtime: where a policy really takes effect

A policy takes effect at two completely different points. At design time, it prevents makers from even inserting and saving a blocked or non-combinable connector into a flow — they get an error message immediately. At runtime, the policy takes effect on flows that have already been saved: if the policy changes afterward, a background process regularly checks all resources of the affected environment. If a flow violates the new rule, it is put into a suspended state and stops running until the violation is resolved. According to Microsoft, when a policy is first introduced, full enforcement can take up to 24 hours in extreme cases, but it is usually completed within an hour.

For Power Automate, there is also an important detail: in the event of violations, the flow status is set to Suspended, and the reason appears as FlowSuspensionReason=CompanyDlpViolation. Anyone querying flows via PowerShell or the admin connector can therefore clearly identify DLP-related suspensions by this value and doesn't have to guess why a flow suddenly stopped.

Who can create policies: tenant and environment level

DLP policies can be set up at two levels, and the permissions required differ accordingly:

• Tenant level: Applies to the entire tenant but can include or exclude specific environments. This requires the Power Platform Administrator role.
• Environment level: Applies to exactly one environment and supplements or tightens the tenant policy, but cannot override it. The Environment Admin role is sufficient here; for environments with a Dataverse database, the System Administrator role is required.

Important to know from the start: environment administrators can neither edit nor delete policies created by a tenant administrator. So if you're starting out at a mid-sized company with only a few people on the IT team, you should clarify early on who holds the tenant role, because that determines who is even able to make changes later.

Step by step: your first DLP policy in the Power Platform Admin Center

The path to a first, working policy runs through a few clearly defined steps:

1. In the Power Platform Admin Center, under Security, open the area Data and Privacy and within it Data policies, then select New policy.

2. Give the policy a descriptive name, for example "Production Environments Standard".

3. Assign connectors, individually or via multi-select, to the Business, Non-business, or Blocked groups. Connectors that cannot be blocked, such as SharePoint, cannot be locked down, but they can still be classified.

4. Set the default group for connectors that will be released in the future. Microsoft recommends leaving this set to Non-business, so that new connectors are neither blocked nor released without review.

5. If needed, add custom connectors to the policy.

6. Define the scope: either exclude specific environments or deliberately include several environments, for example to consciously exempt test and sandbox environments from strict rules.

7. Review the settings on the summary page and create the policy.

After saving, the configuration automatically cascades from the tenant level down into every affected environment, where existing connections and flows are checked against the new rules.

Practical tips for getting started at a mid-sized company

• Start small: A single, moderately restrictive policy for production environments is usually enough to begin with. You can deliberately exclude test environments at first, so that your team can experiment without friction.
• Make policies visible: Share the list of classified connectors internally, so that makers know before building a flow which combinations are allowed. This saves follow-up questions and prevents frustration over blocked flows.
• Leave Non-business as the default: This way, new connectors that Microsoft continuously adds are neither accidentally released nor blanket-blocked until you have deliberately reviewed them.
• Treat violations as a signal, not a nuisance: A suspended flow reliably shows where a process unintentionally tried to move data across group boundaries. This is the point at which DLP actually shows its effect.

Automation with Power Automate pays off especially when digital workers reliably take over recurring tasks without sensitive data moving uncontrolled between services in the process. With a cleanly set up DLP policy, you channel this automation into an orderly framework from the very start, while you as the IT manager retain control at all times over which connector may share data with which.

Frequently asked questions

Does a DLP policy immediately block all existing flows that violate it?

Not immediately in the sense of seconds, but reliably. A background process regularly checks all resources of the affected environment against the current policy. According to Microsoft documentation, full enforcement can take up to 24 hours, but in most cases it is completed within an hour.

Can I exempt individual test environments from a strict policy?

Yes. For tenant-level policies, you define the scope either by excluding specific environments or by deliberately selecting several environments. This allows sandbox or test environments to be deliberately configured more openly than production environments.

What happens when a new connector is released that I haven't classified yet?

It automatically lands in the default group you have set for the policy. Microsoft recommends leaving this default group set to Non-business, so that new connectors are neither blocked nor released for business data without review.

Does a DLP policy also apply to desktop flows, not just cloud flows?

Yes. Power Automate also allows desktop flow modules and individual actions to be classified as business, non-business, or blocked. This makes it possible to prevent a desktop flow from combining actions from different categories, such as database access together with Excel actions from different groups.

Who can change a tenant policy created by the IT department?

Only people with the Power Platform Administrator role at the tenant level. Environment administrators can create supplementary policies for their own environment, but cannot edit or delete tenant-wide policies that originate from central IT.

For more information, see the official Microsoft documentation on Data policies in Power Platform, on Managing data policies in the Admin Center, as well as specifically on Creating DLP policies for Power Automate.