In this article, I’ll walk through all the steps to create a Power Platform DLP policy. If you’ve followed this series so far, you’ll have seen reference to a tenant-wide baseline policy – your ‘catch all’ for any existing environment you specify. It will also automatically gobble up any new environments created.
This scenario will be the basis of the article, though will cover other settings too. There’s a lot to go over, so let’s get cracking.
To create a Power Platform DLP policy, you must log in with an account that has access to the Power Platform Admin Centre (PPAC). Typically, this is an account with the Global or Power Platform Administrator roles in Microsoft 365.
Setting up your tenant-wide baseline policy is ideally supported up front by performing a connector review, conducting an impact assessment, establishing a DLP strategy, and communicating with users. I recommend starting with these items first if you haven’t already covered them.
Create a policy
I walked through most of the steps for creating a policy during the impact assessment article. Some of the steps will repeat here for reference but there’ll be a larger degree of granularity here.
To start, navigate to PPAC. Expand Policies then select Data Policies. Click on New Policy:
Give your policy a name. If you have or are planning to have some kind of naming convention, now’s a good time to implement it.
Click Next at the bottom of the screen to take you to the Prebuilt connectors section.
Prebuilt connectors
In this section, you can assign connectors to the appropriate categories – business, non-business or blocked. For a tenant-wide baseline policy, I’d personally stick with either business or blocked and leave non-business alone. For other policies, you may need all 3 categories.
I mentioned in an earlier article that some connectors can’t be blocked. The first step is to set all those connectors to business and then add these additional services too: Cards for Power Apps, Power Apps for Makers, Power Automate Management, Microsoft Forms.
Connector actions
For each blockable connector, there is an additional setting that you can play with and configure. We can set a connector to business or non-business, but we can also allow or block certain actions within the connector. To access this, click on the ellipsis for the appropriate connector. Navigate through the menu to select Connector actions:
The corresponding actions are displayed here, and you can toggle them with the ‘Allowed’ option if necessary. You can also choose to allow or block new actions. Click on Save to apply the config you have chosen.
Example: I worked with an organisation that wanted the SQL Server connector to align to the business category in its tenant-wide policy. Users were only supposed to retrieve data or send information to execute a stored procedure. The data warehouse team wrote processes to validate, split and update the underlying data when the stored procedures ran. We aligned the SQL Server connector to business, using the following config of connector actions:
You have to make your baseline ‘catch-all’ policy work for your organisation. This added layer of granularity can allow you to extend business connectors whilst still maintaining internal standards and protocols.
Set default group
Another setting in the Prebuilt connectors section of the DLP policy builder is Set default group. This setting is in the upper right corner of this section. Clicking on it will present the following modal:
The default setting here is non-business, which is Microsoft’s recommendation here. However, remember any new connectors added by Microsoft could still be used alone or with other connectors in the non-business category. A maker could see and use a new connector before an admin and build a data leaking flow. Avoid the headaches and update the default group to blocked. Any new connectors that can’t adhere will fall into non-business category.
Click Next to move onto the Custom connectors section.
Custom connectors
Any API that does not have a predefined connector can be contacted by the Power Platform as long as it has an API endpoint to communicate with. Usually this happens via the HTTP action or via a custom connector.
There is a possibility that you may need to include or exclude API endpoints. You can do this as part of your tenant-wide baseline policy, other policies, or both. As part of your tenant-wide baseline policy, I would recommend:
1- Move the HTTP connector to blocked. Safety first – don’t allow anyone to get data in, or post data out of your organisation in case it poses risk.
2- Allow specific API endpoints for custom connectors in your DLP policy.
3- Ensure any non-approved API endpoints for custom connectors are blocked.
By default in a Power Platform DLP policy, any custom connector endpoint is available to use:
Update this to blocked. To do this, click the ellipsis and select Edit:
In the side panel that then shows, selected blocked from the drop down. Don’t forget to hit Save at the bottom of the panel when done.
With that in place, you can then add any API endpoints (aka connector patterns) that you want to allow. You can also align these to business or non-business like you can any other connector:
Before you create a Power Platform DLP policy, you should communicate any custom connector decisions to your makers. You’ll probably need a process to add/approve new custom connector endpoints in a policy.
Not the best UX
When creating a custom connector, it’s not obvious to makers if the endpoint is available or not. They can create the custom connector, but they cannot establish a connection. Depending on the connection type, they may or may not receive a clear error message.
I tested this with a custom connector with no auth. When trying to add a new connection here, it simply keeps the box greyed out but no message as to why:
I can add the custom connector to a flow, but can’t establish a connection there either. Again, no clear message as to why:
Therefore, make sure any custom connector restrictions are well-documented & communicated to users.
Scope
This section of the policy builder defines what environment(s) it will apply to. There are 3 options for you to choose from, for a tenant-wide baseline policy you’ll most likely want the Exclude certain environments option. Let’s break all the options down anyway.
Add all environments.
You might think this is the right option for a tenant-wide baseline policy. The hint text even says “your entire org (tenant). This policy will automatically apply to any new environment that is created“. The problem is that option isn’t flexible. In the previous article in this series, I reviewed some common Power Platform DLP strategies. Most likely, you’ll need an option that lets you choose which environments to cover, plus catch any new environments created.
Add multiple environments.
This gives you a good degree of control. You can manually add environments of your choice to the policy. That means that any environments you don’t select won’t be covered. It also means new environments added after the policy is created aren’t covered either. You’d have to edit the policy and add them manually, though that assumes you’d have a good process for detecting new environments. Either way, adding stuff manually isn’t fun.
Exclude certain environments.
This is the Don Carlo option for a tenant-wide baseline policy. Select the environments you want to exclude, meaning the DLP policy applies to all other environments by default. It also automatically cover any new environments added after the policy is created. You will need some sort of process internally to realign any new environments to different DLP policies. However, a) this is more than manageable and b) it means that new environments will still be covered STRAIGHT AWAY.
Tenant-wide config
In my example, I want to exclude all my personal project environments, which includes my wife’s business solution. I definitely don’t want to break that, or I won’t hear the end of it for at least 3 years. I’ll also want to exclude my CoE starter kit environment because our tenant-wide baseline DLP config would break a number of Power Automate flows. So I’ll add those environments to the policy so they’re excluded:
Any environments left in Available will be the ones that will be subject to the DLP policy:
Review
The final part is simply to review your chosen config. Either edit accordingly or press the Create policy button:
Any apps or flows in conflict with the policy will be instantly affected.
Impact
When you create a Power Platform DLP policy, the experience post-implementation on apps & flows is slightly different. It also depends if the asset has already been created or is in the process of.
New apps
If a maker tries to add a blocked connector, or tries to add both a business and non-business connector, they’ll be presented with a warning message:
Existing apps
Makers get a similar message to above when trying to edit an existing app with a connector conflict. You can still edit the app, but the functionality related to conflicting connectors no longer work.
However, I’ve noticed something different with makers playing/interacting with the app via a link. For testing, I created an app with the Outlook.com connector. I configured a button to send myself an email, then saved and published the app. Then I implemented a DLP policy to block that connector.
When editing the app, I saw an error message right away. However, playing the app took a good 10-15 minutes to decide to register the change:
When you create a Power Platform DLP policy, just keep this in mind. Existing flows are impacted right away but not always for apps.
New flows
Similarly, creating a new flow with connector conflicts will present the maker with an error:
Makers won’t be able to save or test the flow whilst the conflict exists.
Existing flows
Any existing flows with a connector conflict will be instantly turned off and any activity suspended. Trying to turn the flow back on will show the following:
Changes can be saved, but the flow won’t be re-enabled until the connector conflict is resolved:
One super important thing to remember here: Suppose you implement a policy that prevents 100 flows from working due to connector conflicts. When you edit the policy to adjust the connectors so that all of those flows work, you have to manually turn all of the flows back on, one at a time. They do not turn back on automatically.
I speak from experience when I accidentally deployed a policy to an incorrect environment & killed over 250 flows. I was popular that day. I didn’t enjoy manually switching them all back on 🤭
Customise
You can customise parts of the error message content for makers where a connector conflict occurs. Microsoft have done a good job documenting the PowerShell cmdlet you can run. This will update the URL and email address to redirect affected makers to.
What about desktop flows?
Desktop flow actions are available when you create a Power Platform DLP policy. However…
1- you need to enable them in your tenant, and
2- they’re available in Managed Environments only.
I know that Managed Environments have some REALLY good features and that it therefore makes sense to put them behind premium licenses. However, I disagree when it comes to governance, which should be standard no matter what. So I’d like to see desktop flow actions available in Power Platform for any environment type. The job of an Admin is tough as it is.
How to enable
Get yourself over to PPAC. Click on Settings on the left hand side. Select the option for Desktop flow actions in DLP:
From the resulting side panel, click the toggle to Enabled. Make sure you click Save at the bottom of the panel to save changes:
When you create a Power Platform DLP policy with this setting enabled, you’ll see more connectors at your disposal. Filter for Desktop flow to see the additional connectors:
This is an area of Power Platform DLP I’m less familiar with as I’ve not done much in anger with Power Automate Desktop. If you want anymore information for desktop flow stuff in DLP policies, this article is a good place to start.
What about Power Virtual Agents?
Until recently, I wasn’t even aware that additional DLP configurations were required to protect your Power Virtual Agents (PVA) chatbots. When you create a Power Platform DLP policy, multiple PVA connectors are visible. You can assign them to one of the 3 categories and that’s it, right?
So I thought! However, I recently saw this article from Matt Collins-Jones’s blog. Turns out there are further DLP steps to cover PVA to ensure users authenticate properly. Please take a read of Matt’s article and perform the additional actions recommended.
Hopefully this has been a solid guide for setting up a Power Platform DLP policy. In reality it most likely takes a few minutes to set up and implement, the key will be in your preparation and comms beforehand.
If you liked this article and want more epic Power Platform stuff to land in your inbox every week, don’t forget to subscribe 😊
Fantastic and in depth article which includes advice on how to manage partner’s environments!
Thanks Azim
Really good series mate, I think even I have understood!! (but don’t test me!! ;0) )
Thanks for the feedback! It’s an important topic so if others can learn from my ramblings, that’s what it’s all about
Great coverage of topics..i am PP admin and System admin as well but i am not able to see where i can create Environment scope policy. is it possible to create an environment dlp as Power Platform admin. I can not find where I can switch from tenant dlp to environment dlp where I can see the custom connectors and not only the option to set the pattern for categorizing custom connectors.
Hi, if you’re not able to see the admin-related options then perhaps double check your account has the relevant administrative roles. Using the ‘Exclude certain environments’ option in your policy will provide coverage for your whole Power Platform estate for any new or existing environments. You can exclude any environments on a case-by-case basis that way.