If you’re working with Power Apps or Power Automate, chances are you’ve heard about Data Policies or DLP (Data Loss Prevention) policies already. If you haven’t, here’s how Microsoft defines them:
DLP policies enforce rules of what connectors can be used together by classifying connectors as either Business Data only or No Business Data allowed. Simply, if you put a connector in the business data only group, it can only be used with other connectors from that group in the same app.
docs.microsoft.com
On Microsoft Docs, you can find some more information about them and some guidelines are proposed on how to use them within your tenant. Now, in these docs it is always assumed that one and only one policy is applied to each environment in a tenant at any given time. Now I was wondering what happens if you apply multiple data policies to the same environment. I wanted to know how they would interact: would one overrule the other, and if so, which one would “win”? Would they be combined and could this potentially provide advantages? Let’s see what I found and if they are #BetterTogether…
Setting the scene
In order to test out different combinations of data policies, I created a couple of easy Power Automate flows that each contain two to three connectors. The name of the flows describe the connectors used inside. This allows me to easily see which connectors are affected when applying different data policies.
An example of one of these simple flows:
I also created several data policies but didn’t apply them to any environment yet. Here, I used the name of the data policy to describe which connectors are added to the “Business data only” group.
And an example data policy:
With all this in place, we can start experimenting and see what happens.
Applying complementary data policies to an environment
Let’s start simple. I change the environments in the “Teams-Notifications” policy to “Contoso”, and immediately in the overview I see my policy has been applied. Going back to the flow overview, I can see that two of the flows are now suspended. (This last bit can take some time to synchronize and show up.).
The flows that are suspended are those that contain one connector from the “Business data only” group whereas the other is in the “No business data allowed” group: SP-Teams and Teams-Approvals. This is exactly the behavior that is expected from data policies.
Now, let’s go a step further and apply a second policy: SP-Outlook.
Now, an extra flow is suspended: SP-Approvals, because the Approvals and SharePoint connector cannot be used in the same flow according to the new data policy. This means that when applying multiple data policies to one environment, they are all in effect and there is no overruling of one data policy. The groups that are defined in the “Business data only” section of the data policies exist next to each other. That’s clear. However, in this case I only included different connectors in the two different policies, so there is no interference, what happens when I apply multiple data policies including the same connector?
Applying multiple policies for the same connectors
Let’s turn off the SP-Approvals policy and enable the Teams Only policy.
The result: all flows that have combined a Teams connector with another connector are suspended. The other ones are turned on. This means that the least permissive policy regarding the connector used in multiple policies is enforced, even if another policy exists that specifies that these connectors can be combined. The other policy is also still in effect. Note that in this case I don’t have any other flows that combine the Notifications connector with another one, if I did, that one would also be suspended.
Let’s try another case: Teams Only is disabled, SP-Teams is enabled. This leads to even less active flows. All but one are suspended. Any flow that combines SharePoint or Teams with another connector is disabled. (Not pictured but the same would be true for Notifications.)
This leads to the conclusion that different data policies are combined in an AND relationship. Let’s look at it using a venndiagram.
In this diagram we see that when the two policies are applied with a shared connector, we are effectively creating 4 groups of connectors, instead of 2 with a typical data policy. Since there is only 1 connector in 3 of these groups, the flows that are using any of these connectors in combination with another one would be suspended. Any flows that combine connectors that are in the “No business data allowed” group in both data policies will continue to function. We can create a similar diagram for the second situation in the previous section, and will see a similar result.
In this case, 3 groups are created, and there is no overlap since different connectors are included in the Business data only group in both data policies.
What does this mean?
You can use multiple data policies applied to one environment to create multiple groups of connectors that can share data between them and not with any other connectors. However, it is important to be considerate so you don’t unintentionally get isolated connectors.
If you are consciously using multiple data policies, make sure that connectors used in any other policies are all in the same group. Be aware that the least permissive data policy is applied, no extensions to data policy groups can be made by using multiple policies, only complementary groups can be created.
However, data policies still provide little flexibility. I would like to see an option to distinguish between incoming and outgoing data in a lot of connectors. For example, I might want to capture all tweets with a certain hashtag, but I don’t want to automate tweets myself. Another situation that you might encounter is where you want to be able to combine SharePoint with Teams and Teams with Twitter, but maybe not SharePoint and Twitter. This is also not possible with how data policies currently work, unless in different environments.
To conclude, combining multiple data policies can definitely be useful if you want to create more than 2 groups of connectors, with different connectors in each group, to manage your data connections in apps and flows. In this case, they are #BetterTogether.
DigiPersonal 