Power Platform Data Policies vs. Microsoft Purview DLP

Two people in a governance meeting say the word DLP. One means a Power Platform policy that stops a maker combining SharePoint with a social media connector. The other means a Purview policy that scans documents for credit card numbers. They agree enthusiastically, walk away with entirely different pictures, and discover the gap six months later when something goes wrong that neither policy was ever designed to catch.

This confusion is common enough that Microsoft itself has stopped using the term for one of them. In the Power Platform admin center, what everyone still calls DLP policies is now officially named data policies. The rename is a signal worth paying attention to, because it points at the real difference: one of these products never looks at your data at all.

This article explains both, side by side, in plain terms. What each one actually does, how each is set up, when you need one, the other, or both, and the specific misconceptions that create real exposure.

The one distinction that resolves most of the confusion

Power Platform data policies control the plumbing. Purview DLP inspects the water.

A Power Platform data policy governs which connectors can be combined in the same app, flow, or agent. It makes that decision purely by looking at how you classified the connectors. It never opens the file, never reads the record, and never knows whether the data in question was a lunch menu or a patient record.

Purview DLP does the opposite. It performs deep content analysis, not a simple text scan, evaluating primary keyword matches, regular expressions, internal function validation, secondary matches in proximity to the primary match, and machine learning. It cares deeply what the data is and almost not at all about which low code tool moved it.

Hold that distinction and the rest of this article is mostly detail.

Part one: Power Platform data policies

Microsoft’s framing is that data policies act as guardrails to reduce the risk of users unintentionally exposing organizational data. The word unintentionally is doing real work there. These policies are designed for the maker who did not think it through, not the insider who is deliberately exfiltrating data.

Connectors are the unit of control

A core component of Power Apps, Power Automate, and Copilot Studio is the use of connectors to enumerate, populate, push, and pull data. Data policies let administrators control access to those connectors.

A connector at its most basic level is a strongly typed representation of a RESTful API. Wrapping an API into a connector is what makes it usable by a citizen developer through drag and drop rather than through code. That convenience is exactly why connectors are the right control point: they are the doors through which data enters and leaves a low code solution.

Four types matter, and they behave differently in policy.

Certified connectors are tested and certified by Microsoft against standards for security, reliability, and compliance.
Custom connectors let makers integrate systems not covered by the certified set. They are handled as a separate step in the policy wizard, and they deserve more scrutiny than they usually get, because a custom connector is by definition an integration nobody at Microsoft reviewed.
Virtual connectors appear in data policies for administrators to control but are not based on a RESTful API. They exist because data policies became such a popular governance control that Microsoft started surfacing unrelated on and off switches through the same interface, particularly for Copilot Studio features.
Model Context Protocol connectors expose MCP enabled endpoints, known as tools, providing richer generative AI experiences in Copilot Studio. Many nonblockable connectors now support MCP, and these are managed through advanced connector policies.

One forward looking note worth planning around. Advanced connector policies do not support virtual connectors and will not add support, since their focus is real certified connectors. Copilot Studio virtual connectors are evolving into dedicated governance rules separate from both data policies and advanced connector policies, and desktop flow virtual connectors are transitioning to certified connectors. If your governance design leans on virtual connectors today, that ground is moving.

The three data groups, and the rule everyone gets wrong

Every connector sits in exactly one of three groups: Business, Non-business, or Blocked.

Here is the part that trips up almost everyone new to this. Non-business does not mean restricted, and Business does not mean allowed. Connectors in the Business group cannot share data with connectors in other groups, and connectors in the Non-business group cannot share data with connectors in other groups either. The policy prevents combination across groups. It does not rank the groups.

Blocked is the only group that means what its name suggests: those connectors cannot be used at all where the policy applies.

A second detail that quietly matters: the default data group for new connectors. Microsoft adds connectors to the platform continuously, and every new connector lands in whichever group you nominated as the default. The recommendation is to keep this as Non-business so new connectors arrive in a neutral state and can be reviewed and reassigned deliberately.

If you set the default to Blocked instead, blockable new connectors are blocked as expected, but unblockable ones still land in Non-business, because by design they cannot be blocked. Some connectors simply cannot be blocked, and when you try, the Block action is unavailable and a warning appears.

Design time and runtime are two separate impacts

Blocking a connector affects both the maker building something and the things already built, and the distinction explains most confused support tickets.

Design time is the maker experience. If a policy blocks a connector, the maker cannot save an app or flow that uses it and receives an error saying the connector is blocked by policy. That is clear enough.

Runtime is where it gets messier. An app that is running or a flow executing on a schedule at three in the morning will fail with a message that the connection is broken and needs resolution. When the maker then tries to fix the connection, they hit the design time error telling them the connector is blocked by policy. From the maker’s point of view, something that worked yesterday now fails with two different errors that do not obviously point at a policy change.

This is the single strongest argument for communicating policy changes before you make them. Microsoft’s own guidance is that it is good practice for administrators to share the list of data policies with the organization so users know about them before they build.

What actually happens when you save a policy

Understanding the enforcement sequence helps you set expectations with stakeholders who assume a policy takes effect the moment you press save.

The policy configuration is saved at the customer management level.
Configurations cascade down to each environment in the tenant.
Resources in each environment, meaning apps, flows, and chatbots, periodically check for updated policy configurations.
When a change is detected, each app, flow, and chatbot is evaluated for violations.
Violating resources are placed in a suspended or quarantine state so they cannot operate.
Connections are scanned. Where the policy blocks a whole connector, the connection is set to a disabled state.
Anything running that tries to use an inactive connection, action, trigger, or blocked MCP server fails at runtime.

On timing: the more apps, flows, and chatbots you have, the longer full enforcement takes. In most cases it is within an hour. In the most extreme cases, full enforcement takes up to 24 hours.

Plan your change windows around that 24 hour figure rather than the one hour figure. An administrator who makes a policy change on Friday afternoon and leaves may be creating Monday morning problems they will not connect to Friday’s action.

Part two: Microsoft Purview DLP

Purview DLP addresses a different problem entirely: preventing users from inappropriately sharing sensitive data with people who should not have it. Financial data, proprietary data, credit card numbers, health records, national identification numbers.

Content is the unit of control

A Purview DLP policy identifies, monitors, and automatically protects sensitive data across enterprise applications and devices as well as inline web traffic. It does this through deep content analysis rather than a simple text scan, combining keyword matching, regular expression evaluation, internal function validation, proximity based secondary matching, and machine learning.

The practical consequence is that Purview can distinguish between a document mentioning the phrase credit card and a document containing fourteen valid credit card numbers. Power Platform data policies cannot make that distinction, because they never look.

Where it operates

Purview DLP covers substantially more surface area than most people realize, which is part of why the comparison confuses people. Locations include Microsoft 365 services such as Exchange, SharePoint, OneDrive, and Teams chat and channel messages; Office applications including Word, Excel, and PowerPoint; devices running Windows 10, Windows 11, and the three most recent macOS versions; non-Microsoft cloud apps; on-premises file shares and on-premises SharePoint; Microsoft Fabric and Power BI workspaces; and Microsoft 365 Copilot and Copilot chat in preview.

Separately, DLP with collection policies targets inline web traffic, covering unmanaged cloud apps through network traffic and Microsoft Edge for Business. Named targets include OpenAI ChatGPT, Google Gemini, DeepSeek, and Microsoft Copilot, plus over 34,000 cloud apps through the Defender for Cloud Apps catalog using the network option.

That last group is where a lot of current attention sits, and reasonably so. The risk of an employee pasting sensitive material into a consumer AI tool is exactly the kind of thing Power Platform data policies have no visibility into whatsoever.

What it does when it finds something

Purview’s response options are considerably more graduated than the Power Platform’s block or allow. When policy conditions are met, DLP can show a pop-up policy tip warning the user, block the sharing while allowing the user to override and capture their justification, block without an override option, lock and move data at rest to a secure quarantine location, or suppress display of sensitive information in Teams chat.

The override with justification capture is a genuinely valuable middle ground and has no equivalent in Power Platform data policies. It converts a hard block into a documented business decision, which is often what you actually want when a legitimate workflow trips a policy.

All monitored activities are recorded to the Microsoft 365 audit log by default and routed to Activity explorer.

The lifecycle, and the feature Power Platform lacks

A Purview DLP implementation follows three phases: plan, prepare, and deploy in production. Microsoft is unusually candid that this is partly a change management exercise. Adopting DLP might require a change to business processes and a culture shift for users, and a successful implementation depends as much on user training as on well tuned policies.

The deployment sequence is where Purview has a real advantage. You design policies against your control objectives, implement them in simulation mode where the defined actions are not applied, monitor outcomes and fine tune, then enable enforcement. Because simulation applies no actions, you can safely apply a policy to all workloads at once to get the full breadth of results.

Tuning while in simulation typically covers adjusting which locations and people are in scope, refining match conditions, refining sensitive information definitions, and adding controls, people, restricted apps, or restricted sites. One quirk to know: the stop processing more rules option does not work in simulation mode even when turned on. Once enabled, policies generally take effect about an hour later.

Power Platform data policies have no equivalent to simulation mode. You cannot preview which existing apps and flows a proposed classification would break. This asymmetry should shape how you approach each product, and it is the single most practically useful difference in this entire article.

Visibility after deployment

Purview provides an Overview page covering policy sync status, device status, top activities detected, and device health. Alerts appear in the DLP Alerts dashboard where they can be triaged, given an investigation status, and tracked to resolution, and are also routed to the Microsoft Defender portal.

Two retention numbers are worth writing down, because they differ and people assume they do not. DLP alerts are available in the Microsoft Defender portal for six months, but only for 30 days in the Purview DLP alerts dashboard. Activity explorer holds the last 30 days of DLP information.

One behavioral difference worth internalizing: alerts are generated differently for email than for SharePoint or OneDrive. In SharePoint and OneDrive, DLP scans existing items as well as new ones. In Exchange, new messages are scanned, but DLP does not scan previously existing email stored in a mailbox or archive.

Side by side

The row people should look at hardest is licensing. Power Platform data policies are available to you today as part of the platform. Purview DLP requires appropriate Microsoft 365 compliance licensing. For many organizations this means the Power Platform control is available immediately while the Purview control is a procurement conversation, which is a good reason to get the Power Platform side right rather than waiting.

Four misconceptions that create real exposure

We have Purview DLP, so Power Platform is covered

This is the most expensive of the four. Purview DLP does not evaluate connector combinations in Power Apps or Power Automate. A flow that pulls records from a line of business system and pushes them to an unapproved destination is not a scenario Purview DLP is architected to catch, because there is no document, no email, and no endpoint activity in the path it monitors. Purview covers Fabric and Power BI workspaces, which people sometimes read as covering Power Platform generally. It does not.

We have Power Platform data policies, so sensitive data is protected

Equally wrong in the other direction. A data policy will happily permit a flow that moves a spreadsheet of national identification numbers between two connectors you both classified as Business. It has no concept of what is in the spreadsheet. Classification is a statement about the connector, not about the data.

Non-business means the connector is restricted

Covered above, but it belongs in this list because it produces a specific failure. Administrators put connectors they are unsure about into Non-business believing they have limited them, when what they have actually done is grouped them together and allowed them to interoperate freely with each other. If the intent is restriction, the connector belongs in Blocked.

The policy takes effect when I save it

Enforcement cascades and evaluates over time, up to 24 hours in the largest tenants. Testing a policy change five minutes after saving and concluding it did not work is a common and avoidable mistake.

Setting up a Power Platform data policy

You need either Environment Admin or Power Platform admin permissions. Tenant-level policies require the Power Platform Administrator role. Environment-level policies require Power Apps Environment Admin permissions, or the System Administrator role for environments with a Dataverse database.

The process has five steps: name the policy, classify connectors, define the scope, select environments, and review.

Step one: get to the right page

Sign in to the Power Platform admin center, select Security in the navigation pane, then under Settings select Data and privacy. In the Data protection and privacy screen, select the Data policy section and choose New Policy.

Step two: classify prebuilt connectors

The Assign connectors screen lists every connector with several attributes worth understanding before you start clicking. Name is sortable. Blockable indicates whether the connector can be blocked at all. Class indicates whether the connector requires a premium license or is included in the standard licensing. Publisher shows who publishes the connector, which is not necessarily who owns the underlying service, since Microsoft may publish a connector for a third party service. About links to more detail.

Select connectors and use Move to Business, or the ellipsis beside a connector name, to assign them. Search works across any field in the list view including name, blockable, type, and publisher, which is the only sane way to work through a list this long.

Before moving on, set the default group for new connectors using Set default group in the upper right. As discussed, Non-business is the recommended setting.

Step three: custom connectors

The Custom connectors page lets you select which custom connectors to include in the policy. Do not skip past this. Custom connectors are integrations your organization built, which means nobody outside your organization has assessed them.

Step four: scope and environments

The Scope page does not appear for environment-level policies, which by definition target a single environment. For tenant-level policies you choose whether to add multiple environments or exclude certain environments.

The Environments page then lists environments with name, ID, type, region, created by, and creation date. Tenant admins see all environments in the tenant. Environment admins see only the subset they manage.

Be careful here, because this is genuinely confusing in the product. What the Available and Excluded from policy pivots represent changes depending on whether you selected Add multiple environments or Exclude certain environments. Read the review screen properly before creating the policy rather than trusting your reading of the pivots.

Step five: review and create

Review the settings and select Create policy. The policy appears in the data policies list, showing scope, what it is applied to, and who created and modified it.

Two governance rules about editing

Environment admins cannot edit or delete policies created by the tenant admin. And environment-level data policies cannot override tenant-wide data policies. Together these give you a clean delegation model: tenant policy sets the floor, environment admins can add restrictions above it, and nobody below tenant level can weaken what you set.

One optional step worth knowing about: you can enforce data policies on existing connections through PowerShell. This disables existing connections that violate policies, and re-enables previously disabled connections that no longer violate any policy.

Data policies can also be managed through PowerShell commands and the Power Platform data policies SDK, which matters if you manage policy as code or need to apply consistent classification across many tenants.

Setting up a Purview DLP policy

All Purview DLP policies are created and maintained in the Microsoft Purview portal. Every policy, whether from a template or built from scratch, requires the same five decisions.

Choose what to monitor. Either a predefined template such as financial data, medical and health data, or privacy data for a given country or region, or a custom policy using sensitive information types, retention labels, and sensitivity labels.
Choose administrative scoping. Administrative units can be assigned to some enterprise applications and devices policies, so that administrators assigned to a unit can only create and manage policies for the users, groups, and sites they are assigned to.
Choose where to monitor. One or more locations, each with its own inclusion and exclusion mechanism: Exchange by distribution group, SharePoint by site, OneDrive by account or distribution group, Teams by account or distribution group, devices by users and groups plus devices and device groups, Defender for Cloud Apps by instance, on-premises repositories by file path, Fabric and Power BI by workspace, and Microsoft 365 Copilot by account or distribution group.
Choose the conditions. Preconfigured or custom. Examples include an item containing a specified type of sensitive information used in a certain context, such as 95 national identification numbers being emailed outside the organization; an item carrying a specified sensitivity label; or an item with sensitive information being shared internally or externally.
Choose the action. Actions depend on the location. Blocking external access in SharePoint, Exchange, or OneDrive with a policy tip and email notification. Blocking sensitive information sharing in Teams. Auditing or restricting copying to removable USB on devices. Popups with block or block with override in Office apps. Moving files to a quarantine folder on on-premises file shares.

The conditions and actions together are defined in an object called a rule, which is worth knowing because the terminology differs from the Power Platform side where a policy is the whole thing.

Once created, the policy is stored in a central policy store and synced to content sources including Exchange and from there to Outlook on the web and Outlook, OneDrive, SharePoint sites, Office desktop programs, and Teams channels and chat messages. Enforcement begins once the sync completes.

Different locations have different prerequisites. Exchange Online can be brought under DLP simply by configuring a policy that applies to it, while on-premises file repositories require deploying the Microsoft Purview Information Protection scanner. Budget for that difference during planning.

Implementation: which one, and in what order

If you take away one operational recommendation, take this one. Because Power Platform data policies have no simulation mode and no native alerting, and because they can suspend running apps and flows, treat them as a change management exercise rather than a configuration task. Purview gives you simulation to discover impact. Power Platform makes you discover impact in production.

A workable sequence for an organization starting from nothing.

Inventory before you classify. Find out which connectors are actually in use across your tenant and in which environments. Classifying blind is how you break a business critical flow nobody told you about.
Start with Blocked, not Business. The clearest early win is blocking connectors your organization has no legitimate use for, particularly consumer services. This is low risk because nothing legitimate depends on them.
Set the default group deliberately. Non-business, so that new connectors arrive neutral rather than surprising anyone.
Exclude your development and test environments initially. Give makers somewhere to work while you tune, then bring those environments in once your classification is stable.
Communicate before enforcing. Publish the classification. The design time and runtime error messages do not tell makers why something broke, so your communication has to.
Then build the Business group. This is the more disruptive step because it constrains combinations makers may already rely on. Do it after you have a working communication channel.
In parallel, start Purview in simulation mode. Because simulation applies no actions, there is no reason to delay. Apply broadly, gather results, and tune before enabling anything.
Enable Purview enforcement one workload at a time. Start where the sensitive data actually lives rather than everywhere at once.
Review the connector list quarterly. New connectors arrive continuously and land in your default group. That group is a queue, not a destination.

A reference posture

If your concern is	The right control is	Because
A maker connecting a business system to a consumer service	Power Platform data policy	This is a connector combination problem and Purview has no visibility into it
Customer records being emailed outside the organization	Purview DLP	This requires knowing what is in the message, which data policies never inspect
Employees pasting sensitive material into consumer AI tools	Purview DLP with inline web traffic	The activity happens in a browser, entirely outside Power Platform
A specific connector action being dangerous while the connector is needed	Advanced connector policies	Classic data policies operate at connector level, not action level
Copilot Studio features needing to be turned off	Virtual connectors today, dedicated rules in future	Microsoft is moving these out of data policies into their own governance rules
Sensitive data in Fabric or Power BI workspaces	Purview DLP	These are supported Purview locations

The short version

Power Platform data policies answer the question can these connectors be combined. They never inspect content, they are included with the platform, they enforce at both design time and runtime, and they have no simulation mode to protect you from your own mistakes.

Purview DLP answers the question does this item contain sensitive data and is this action acceptable. It inspects content deeply, spans far more of your digital estate than Power Platform alone, offers graduated responses including override with justification, and requires compliance licensing.

They are not alternatives, they are not competitors, and neither one covers the other’s gap. Microsoft renaming the Power Platform capability to data policies was an attempt to stop this exact confusion. Adopting that language internally costs nothing and prevents the meeting described at the top of this article.

Questions

Data governance decisions rarely fit a template, and the right answer usually depends on your environment structure, licensing position, and what your makers have already built. If you have a question about anything covered here, or want a second opinion on a policy design before you enforce it, reach out at support@powerplatformengineer.com.

Sources

Connector classifications, Purview locations, and licensing requirements change regularly. Verify current behavior in Microsoft Learn and in your own tenant before acting on any configuration guidance here.