Introduction

A single Power Automate flow can move a new Dataverse contact record to a personal Gmail account in seconds. A Power Platform DLP policy helps stop that transfer before business data leaves an approved system.

Connectors make low-code development possible, but they also create data movement paths between services. A DLP policy controls which connectors can work together, blocks unsafe services, and applies these rules across selected environments. It helps keep business data secure and under proper control.

Watch the DLP Policy in Power Platform video on YouTube

Why Connectors Matter in Power Platform

Connectors link Microsoft Power Platform with services such as Dataverse, SharePoint, SQL Server, Salesforce, Gmail, Dropbox, Facebook, and Office 365 Outlook. Each connector can access, send, store, or change data in another system.

Connectors act as no-code wrappers for web API calls

A connector provides a ready-made interface for communicating with another service through web API calls. You can connect a flow or app to SharePoint without writing the API code by hand.

Before approving a connector, check which service it reaches, what data it can access, and whether the service is approved for business use. A connector may be easy to add, but it still creates a path into or out of your organization.

Power Automate moves data between systems

Power Automate uses triggers and actions to move information between systems. For example, a flow can start when someone adds a contact in Dataverse, then send an email through Outlook or store details in SharePoint.

This automation can save time, but an unsafe flow can repeat a data transfer without further review. A DLP policy adds a control layer that limits which destinations developers can use.

How a Power Platform DLP Policy Controls Connectors

A DLP policy controls how connectors work together inside a Power Platform environment. It does not only assess connectors one at a time. It also restricts combinations between connector groups.

Business connectors support approved work

Business connectors are trusted services approved for use with organizational data. Common examples include Dataverse, SharePoint, Office 365 Outlook, and Excel Online.

The demonstration also places Tata in the Business group. Your own classifications should follow your company’s security rules, data needs, and compliance requirements. A connector belongs in this group only after the organization approves its use.

Non-business connectors stay separate

Non-business connectors may support personal or external use cases, but they should not combine with Business connectors. Gmail is a common example when an organization allows it for limited personal or external tasks.

If Dataverse is in the Business group and Gmail is in the Non-business group, a flow cannot use both connectors together under the policy. This separation reduces the chance of sending company records to an account outside organizational control.

Blocked connectors cannot be used

Blocked connectors are unavailable in apps and flows covered by the policy. Use this group for services that could expose business information or cannot meet your security requirements.

In the demonstration, Gmail and another external connector are moved to Blocked. A developer then cannot sign in to or add those connectors within the governed environment.

Stop Unsafe Data Paths Between Services

The Dataverse-to-Gmail example shows why connector rules matter. Dataverse may hold customer or contact records, while a personal Gmail account may not have the same security controls as the organization.

Dataverse-to-Gmail creates a disclosure risk

The sample flow starts when a new contact record is added to Dataverse. It then attempts to send contact data through Gmail.

Power Automate can perform this transaction when no policy prevents it. If the Gmail account is personal, the business data may leave systems managed by the organization.

Connector groups block incompatible combinations

When Dataverse is classified as Business and Gmail is classified as Non-business or Blocked, the policy prevents the connection based on the selected rules. Non-business connectors may still work for approved non-business tasks, but they cannot share data with Business connectors.

A Blocked connector has a stricter result. It cannot be used in the governed environment, even for a flow that does not connect it to a Business service.

Enforcement appears during flow creation

After Gmail is blocked, adding Gmail as an email action causes an error in the sample flow. The connector cannot complete sign-in, and the request fails.

This result shows that DLP enforcement works at the platform level. Developers cannot bypass the rule by creating a new flow or adding the connector later.

Configure a Power Platform DLP Policy

Administrators create and manage policies in the Power Platform admin center. Microsoft may change menu names and locations over time, so the exact screen can differ from the demonstration.

Open Data Policies in the admin center

Open the Power Platform admin center, then go to Security, Data and privacy, and Data policy. Select New policy to begin.

Give the policy a clear name, such as “HSBC policy.” Before saving it, define the business owner, target environments, connector rules, and any exception process.

Classify standard connectors

The demonstration shows about 1,712 connectors available at that time. This number can change as Microsoft adds or updates connectors.

The screen initially treats connectors as Non-business in the demonstration. The administrator then moves SharePoint, Office 365 Outlook, Dataverse, Tata, and Excel Online to Business. Gmail is moved to Blocked.

Use the search box to find connectors quickly. Record the reason for each classification so future administrators understand why a service was approved, separated, or blocked.

Select the environments covered by the policy

A DLP policy must apply to one or more Power Platform environments. You can apply it to all environments, select environments such as QA and UAT, or exclude a chosen environment.

Review your development, QA, UAT, and production needs before choosing the scope. A broad policy may affect testing flows that use external services, while a narrow policy may leave sensitive production data unprotected.

After reviewing the connector groups and environment scope, select Create policy. Administrators can later edit or delete the policy, but treat every change as a controlled governance change.

Govern Custom Connectors and Verify Policy Results

Prebuilt connectors are only part of the risk. Custom connectors can call external APIs that your organization has not reviewed.

Review custom connectors and API hosts

A custom connector is built around an external API endpoint. It can give developers access to services that do not have a standard Power Platform connector.

Maintain a record of each custom connector, including its owner, API host, authentication method, data accessed, and business purpose. Technical access alone does not make an API suitable for company data.

Block risky external endpoints

The demonstration adds a host or URL pattern for the currency-layer API, which provides current currency exchange rates. The pattern is assigned to the Blocked group.

Custom connectors that attempt to reach that host are then restricted. Use precise patterns and test approved integrations so a rule does not block a service that the business needs.

Test both blocked and approved flows

To test enforcement, create an automated Power Automate flow with a Dataverse trigger for a new contact record. Add Gmail as the email action and confirm that the connector cannot authenticate or save successfully.

Then test approved Business-to-Business combinations. Check connection sign-in, flow saving, activation, solution import, and runtime execution. Use test data and a non-production environment during validation.

Review classifications whenever you add a connector, create an environment, approve a custom API, change data sensitivity, or update compliance rules. Assign an owner to review the policy on a regular schedule.

Conclusion

A Power Platform DLP policy controls how data moves between connectors. Business connectors can work with approved organizational data, Non-business connectors remain separate, and Blocked connectors cannot be used in covered environments.

The setup is direct: create the policy in the Power Platform admin center, classify standard connectors, govern custom API hosts, choose the right environments, and test the result. The Dataverse-to-personal-Gmail scenario shows the benefit clearly: once Gmail is blocked, the flow cannot use it to transfer contact data.

Review your connector inventory and environment scope before your next Power Platform deployment. Then test the policy with both approved and prohibited flows so your rules work in practice, not only on paper.