Data loss prevention policies
Your organization's data is likely one of the most important assets you're responsible for safeguarding as an administrator. The ability to build apps and automation to use that data are a large part of your company's success. You can use Power Apps and Power Automate for rapid build and rollout of these high-value apps so that users can measure and act on the data in real time.Apps and automation are becoming increasingly connected across multiple data sources and multiple services. Some of these might be external, third-party services and might even include some social networks. Users generally have good intentions, but they can easily overlook the potential for exposure from data leakage to services and audiences that shouldn't have access to the data.
You can create data loss prevention (DLP) policies that can act as guardrails to help prevent users from unintentionally exposing organizational data. DLP policies can be scoped at the environment level or tenant level, offering flexibility to craft sensible policies that strike the right balance between protection and productivity. For tenant-level policies you can define the scope to be all environments, selected environments, or all environments except ones you specifically exclude. Environment-level policies can be defined for one environment at a time.
DLP policies enforce rules for which connectors can be used together by classifying connectors as either Business or Non-Business. If you put a connector in the Business group, it can only be used with other connectors from that group in any given app or flow. Sometimes you might want to block the usage of certain connectors altogether by classifying them as Blocked.
DLP policies are created in the Power Platform admin center. They affect Power Platform canvas apps and Power Automate flows. To create a DLP policy, you need to be a tenant admin or have the Environment Admin role.
The ability to block connectors by using a three-way classification—Business, Non-Business, and Blocked—in addition to DLP policy UI support in the Power Platform admin center are currently in public preview. There is new DLP policy PowerShell support for three-way DLP policy classification, which is also in public preview. Legacy DLP policy support for two-way classification (Business and Non-Business), along with admin center UI and PowerShell support for two-way classification, are currently generally available and will continue to be available for the foreseeable future. More information: Connectors documentation
Data groups are a simple way to categorize connectors within a DLP policy. The three data groups available are the Business data group, the Non-Business data group, and the Blocked data group.
A good way to categorize connectors is to place them in groups based on the business centered or personal-use centered services that they connect to in the context of your organization. Connectors that host business-use data should be classified as Business and connectors that host personal-use data should be classified as Non-Business. Any connectors that you want to restrict usage of across one or more environments should be classified as Blocked.
When a new policy is created, by default all connectors are placed in the Non-Business group. From there they can be moved to Business or Blocked based on your preference. You manage the connectors in a data group when you create or modify the properties of a DLP policy from the admin center. See Create a data loss prevention (DLP) policy. You can also change the initial classification of connectors by editing your DLP policy. See Edit a DLP policy.
Until recently, some HTTP connectors weren't readily available for DLP policy configuration by using the DLP policy UI or PowerShell. As of May 2020, the following HTTP connectors can now be classified by using the DLP policy UI and PowerShell, like any other Power Platform connector: HTTP, HTTP Webhook, and When a HTTP request is received. If legacy DLP policies are being updated using the new DLP UI, a warning message will be displayed to admins indicating that these three HTTP connectors are now being added to the DLP purview and that they should ensure that these connectors are placed in the right DLP grouping.
The Content Conversion connector is an integral feature of Power Platform, used to convert an HTML document to plain text. It applies both to Business and Non-Business scenarios and doesn't store any data context of the content converted through it; therefore, it's not available for classification through DLP policies.
How data is shared among data groups
Data can't be shared among connectors that are located in different groups. For example, if you place SharePoint and Salesforce connectors in the Business group and you place Gmail in the Non-Business group, makers can't create an app or flow that uses both the SharePoint and Gmail connectors. This in turn restricts data flows between these two services in Power Platform.
Although data can't be shared among services in different groups, it can be shared among services within a specific group. From the earlier example, because SharePoint and Salesforce were placed in the same data group, makers can create an app or flow that uses both SharePoint and Salesforce connectors together. This in turn allows data flows between these two services in Power Platform.
The key point is that connectors in the same group can share data in Power Platform, whereas connectors in different groups can't share data.
The effect of the Blocked data group
Data flow to a specific service can be blocked altogether by marking that connector as Blocked. For example, if you place Facebook in the Blocked group, makers can't create an app or flow that uses the Facebook connector. This in turn restricts data flows to this service in Power Platform.
All third-party connectors can be blocked. All Microsoft-owned premium connectors (except Common Data Service) can be blocked.
Standard licensed connectors, where the service is owned by Microsoft, can't be classified as Blocked through DLP policies. They can be classified into Business or Non-Business data groups. These connectors broadly fall into following categories:
- Enterprise-class Microsoft 365 suite of services with no additional licensing implications.
- Power Platform–specific connectors that are part of the base platform capabilities.
- Private use–only Microsoft connectors, such as Outlook.com. These connectors don't support corporate sign-ins, they only support Microsoft account sign-ins. We recommend that you classify these connectors in the Non-Business category.
- Common Data Service connectors. These are the only premium connectors that can't be blocked, because Common Data Service is an integral part of Power Platform.
The following connectors can't be blocked by using DLP policies.
Office connectors (standard)
|Power Platform connectors (standard)||Personal use
Office connectors (standard)
|Other Microsoft connectors (standard)||Exception for premium connectors|
|Excel Online (Business)||Approvals||Excel||Azure AD||Common Data Service|
|Microsoft Forms||Notifications||Excel Online (OneDrive)||Bing Maps|| Common Data Service
|Microsoft Forms Pro||Power Apps for Admins||OneDrive||Bing Search|
|Microsoft Teams||Power Apps for Makers||Outlook.com||Cloud App Security|
|Microsoft To-Do (Business)||Power Apps Notification||Computer Vision API|
|Microsoft 365 Groups||Power Automate for Admins||Content Conversion|
|Microsoft 365 Outlook||Power Automate Management||Content Moderate|
|Microsoft 365 Users||Power BI||Custom Vision|
|Microsoft 365 Video||Power Platform for Admins||Face API|
|OneDrive for Business||Form Recognizer|
|Outlook Customer Manager||LinkedIn V2|
|Project Online||Microsoft School Data Sync|
|Skype for Business Online||MSN Weather|
|Video Indexer (V2)|
Custom connector classification
By default, custom connectors aren't part of the standard configuration capabilities of DLP policies in the Power Platform admin center. However, you can use DLP policy PowerShell commands to set them up into Business, Non-Business, and Blocked groups. More information: Data Loss Prevention (DLP) policy commands
Unlike standard and premium connectors, which are available to all environments in the tenant, custom connectors are scoped specifically to an individual environment. Therefore, you can't use tenant-level DLP policies to manipulate custom connectors, you must use environment-level DLP policies. By using PowerShell, you can configure DLP policy to include these connectors. After they're added, they can then be managed in the admin center.
Only custom connectors that are stored in a tenant's default environment will be displayed with their associated icon and display name in the policy editor. All other custom connectors will be displayed with the default connector icon and their internal name.
Default data group for new connectors
One data group must be designated as the default group to automatically classify any new connectors added to Power Platform after your policy has been created. Initially, the Non-Business group is the default group for new connectors and all services. You can change the default data group to the Business or Blocked data group, but we don't recommend that you do so.
Any new services that are added to Power Apps will be placed in the designated default group. For this reason, we recommend you keep Non-Business as the default group and manually add services into the Business or Blocked group after your organization has evaluated the impact of allowing business data to be shared with the new service.
Microsoft-owned standard connectors are exempt from being marked as Blocked and can only be classified as Business or Non-Business. If Microsoft adds any new connectors that can't be blocked and if you've set the default group for the DLP policy as Blocked, these connectors will be automatically marked as Non-Business instead of Blocked.
DLP policies can be created at both the tenant and environment level. Tenant admins have the permissions to create tenant-level policies; environment admins have the permissions to create environment-level policies.
Tenant admins can define three types of scopes for tenant-level data policies:
Option 1: Apply to all environments
Option 2: Apply to multiple environments (but not all)
Option 3: Apply to all environments except certain specifically excluded ones
It's typical for tenant admins to define DLP policies for their entire tenant but exclude certain environments, as described in option 3. For the excluded environments, tenant admins can define alternate DLP policies and apply them to multiple environments, as described in option 2. Option 1 is for DLP policy rules that must apply across the entire tenant, without exception.
Tenant admins can define more than one multiple-tenant–level policy for the environments in their tenant. These policies can be set for mutually exclusive or overlapping environment scopes.
Environment admins can define environment-level data policies for one environment at a time. Environment admins can't exclude their environments from tenant-level policies. Therefore, all the restrictions defined by the tenant admins scoped for their environment still apply, in addition to any environment-level policy that they have individually defined for their environment.
As is true of tenant admins with tenant-level policies, environment admins can define more than one environment-level policy for their environment.
Even though environment admins might manage more than one environment, they can't include more than one environment in the environment-level policy. They must define individual environment-level policies for each environment that they manage.
Combined effect of multiple DLP policies
As tenant or environment admins, you can create more than one DLP policy and apply it to the same environment. At design and runtime, all policies that are applicable to the environment in which the app or flow resides are evaluated together to decide whether the resource is in compliance or violation of DLP policies.
Blocked classification impact across multiple policies
If any policy (tenant-level and/or environment-level) that's applicable to an environment marks a connector as Blocked, no app or flow can use that connector in the environment. It doesn't matter whether any other policy classifies that connector as Business or Non-Business, because Blocked is the most restrictive classification for the connector; therefore, Blocked is always the final outcome of multiple policy evaluations.
Business/Non-Business classification impact across multiple policies
Compared to evaluating the effect of the Blocked classification, evaluating the effect of the Business or Non-Business classification across multiple policies is more complex. You can can classify a given connector, such as SharePoint, as Business in policy A and as Non-Business in policy B. What matters is what other connectors SharePoint is grouped with across policy A and policy B.
Note that the most restrictive grouping is finally imposed when all the policies applicable to an environment are evaluated together. Consider an example of three policies (A, B, and C) across ten connectors (SharePoint, Twitter, Salesforce, Facebook, Face API, Microsoft 365 Outlook, Basecamp 3, Adobe Sign, Azure Blob Storage, and Box). These connectors are classified as Business or Non-Business as represented by two categories each across the three policies (-E1-, -E2-, -E3-, -E4-, -E5-, and -E6-).
-E1- Business – SharePoint, Twitter, Salesforce, Microsoft 365 Outlook, Basecamp 3
-E2- Non-Business – Facebook, Face API, Adobe Sign, Azure Blob Storage, Box
-E3- Business – SharePoint, Facebook, Face API, Microsoft 365 Outlook, Basecamp 3
-E4- Non-Business – Twitter, Salesforce, Adobe Sign, Azure Blob Storage, Box
-E5- Business – Facebook, Face API, Twitter, Salesforce, Microsoft 365 Outlook
-E6- Non-Business – SharePoint, Adobe Sign, Azure Blob Storage, Box, Basecamp 3
When all three policies are applied together to the same environment, the net result is fragmentation of connectors across eight (23 = 8) groups, as depicted below. Only connectors in the same group (out of eight possible combinations) can be used in a given app or flow.
-E1-, -E3-, -E5- Group 1 – Microsoft 365 Outlook
-E1-, -E3-, -E6- Group 2 – SharePoint, Basecamp 3
-E1-, -E4-, -E5- Group 3 – Twitter, Salesforce
-E1-, -E4-, -E6- Group 4 – NULL
-E2-, -E3-, -E5- Group 5 – Facebook, Face API
-E2-, -E3-, -E6- Group 6 – NULL
-E2-, -E4-, -E5- Group 7 – NULL
-E2-, -E4-, -E6- Group 8 – Adobe Sign, Azure Blob Storage, Box
To summarize: an app or flow can only use connectors from these individual groups at any given time, and not mix connectors across the eight different groups. From the examples above, note that multiple DLP policies applied to an environment will fragment your connector space in complicated ways. Therefore, we highly recommended that you apply a minimum number of DLP policies to any given environment.
Impact of DLP policies on apps and flows
If admins have disallowed certain connectors to be used together in an environment by classifying them as Business or Non-Business—or marked certain connectors as Blocked by using tenant-level or environment-level DLP policies—these restrictions can negatively affect makers and users of Power Apps and Power Automate. The restrictions are enforced at both design time and at runtime.
As an admin, you should have a process and plan in place to handle these types of support needs if you're using DLP policies.
Design-time impact on apps and flows
Users who create or edit a resource affected by the DLP policy will see an appropriate error message about any DLP policy conflicts. For example, Power Apps makers will see the following error when they use connectors in an app that don't belong together or have been blocked by DLP policies. The app won't add the connection.
Similarly, Power Automate makers will see the following error when they try to save a flow that uses connectors that don't belong together or have been blocked by DLP policies. The flow itself will be saved, but it will be marked as Suspended and won't be executed unless the maker resolves the DLP violation.
Runtime impact on apps and flows
As an admin, you can decide to modify the DLP policies for your tenant or for specific environments at any point. If apps and flows were created and executed in compliance with an earlier DLP policy, some of them might be negatively affected by any policy changes you make.
Users who use a resource that's in violation of the latest DLP policy will see an error message about the DLP policy conflict. For example, Power Apps makers and users will see the following error when they try to open an app that uses connectors that don't belong together or have been blocked by DLP policies.
Similarly, Power Automate makers and users won't be able to start a flow that uses connectors that don't below together or have been blocked by DLP policies. A background system process marks the flow as Suspended, and the flow won't be executed until the maker resolves the DLP policy violation.
The flow suspension process works in a polling mode. It takes about five minutes for the latest DLP policy changes to be assessed against active flows to mark them as suspended due to DLP policy violations. This change isn't instantaneous.
The ability to block connectors by using DLP policy and DLP policy support in the Power Platform admin center UI are in public preview. We're working to address the following known issues and limitations:
- Tenant-level policies created through the new UI enforce default grouping (typically non-business) on custom connectors. Currently there is no way to explicitly classify custom connectors in tenant-level policies or ignore them altogether. In order to manage custom connector settings explicitly using environment-level policies, exclude these environments from the tenant-level policies.
- Sorting by Created and Modified fields on Data Policy list view doesn’t work correctly.
- Three-way DLP policy creation isn't available through admin connectors. Also, the Power Platform for Admins connector always blocks LBI/Non-business group.
- If the default group is set as blocked, the list of connectors that can't be blocked won't apply when you use PowerShell to create DLP policies.
- All check boxes present while creating a new policy appear to have been selected when you select Review on the Data Policies page.
- Canvas apps assessment for DLP violations at launch time/run time does not work as expected.