At the beginning of my journey into Microsoft Flow, there were a couple of questions that came up early, that were not directly related to what Microsoft Flow could do in the automation arena. Those were:

1. How do I protect my data from being shared with a service that is not approved by the company? Or another way of looking at it, how do I disable connectors I don’t want to be used. 
2. How do establish an environment that allows my end-users to explore and work with Flow with minimal risk to the companies data?

At Collaborate Canada in Toronto recently, Éric Sauvé used the phrase “Be Safe, not Sorry” when describing Data Loss prevention Policies and I think it is a perfect phrase of why you should spend time to establish what your policies will be not just on your Dynamics 365 environments, but for all CDS environments in your organization.

Let’s Explore Data Loss Prevention Policies (DLP)

Head over to http://admin.flow.microsoft.com you will see a section on the left hand side labelled Data policies.   If any exist you will see them listed here. If not, in the upper right lets click on New Policy button.

Which Environment? 

The first choice you have to make is which environment do you want to apply the current Data Loss prevention policy too:

1. Apply to ALL environments – This includes CDS, so D365, any environment that you’ve built for PowerApps or flow. This includes all Sandbox environments Production and your Default CDS environment.
2. Apply to Only Selected environments – Selecting this option will give you a chance to pick and choose which environment you apply the current DLP too.
3. Apply to ALL environments EXCEPT – this is the invert of the option above, where you can say apply this DLP to everything BUT the environments I select (and you can choose multiple in one step.

Data Groups: This is the heart of DLP

• Business Data: This is a collection of connectors that you are approving to talk to each other. As the name suggests you want to put connectors in here that are allowed to interact with your business data. 

• No Business Data: This is the collection of connectors that you are also, approving to talk to each other, but these are the connectors that we don’t’ want to talk to your business data. 

A connector from one data group cannot talk to a connector from the other data group. However, connectors in the same data groups can still talk to each other. Lets look closer below:

• Example 1: We can have a Flow that has Common Data Service and Approvals together.
• Example 2: We can have a flow that has SharePoint and SQL Server together
• Example 3: We cannot have Office 365 in the same flow as DropBox

Disable a Connector

With a Single DLP in place like we have in Figure 3, Twitter can still talk to the rest of my connectors my ‘No Business Data’ group. This can be an issue if for example, you want to block any Flow from using Twitter in your environment.

We want to put twitter in a DLP where we isolate the twitter connector on its own in the Business Data group. We then add all other connectors to the No Business Data group. The effect of this DLP is that Twitter can no longer talk to any other connector in that environment.

Stacking Data Loss prevention Policies

We cannot build one DLP to rule them all. So you will need to apply or stack multiple data loss prevention policies to your environment to get the net effect that you are looking for.

For example, we can take our D365 DLP from above in Figure 3 and apply it to our environment on its own. The Twitter connector is grouped in the No Business data group with a lot of other connectors including things like SharePoint, One Drive and Azure related services. Which means end users could create Flows in that environment that would connect Twitter with a SharePoint list containing sensitive client data. Not ideal.

If we add in our Twitter isolation Data loss prevention policy in Figure 4, the two policies stack together. That is, the environment will take on the most restrictive combination of the data loss prevention policies so you will be unable to leverage the Twitter with either Flow or Power Apps that are built on top of that particular CDS environment.

Take Away notes

1. When combining multiple Data loss prevention policies, the most restrictive security is applied. 
2. When new connectors are published to Flow; they will automatically be added to the No Business Data groups of your defined data loss prevention policies.
3. When your data loss prevention policies are updated, it will disable any active Flows no longer adhere to the DLP.
4. A data loss prevention policy will not prevent you from seeing or including connectors from the no business data group in your Flows. It just prevents the Flows from being activated. So users can still explore and build Flows with connectors from Business Data and No Business Data groups.
5. As a best practice; Consider defining an Enterprise DLP (Or a group of DLPs) that is applied to all CDS environments regardless of its intended use as a starting point to ensure that all CDS environments are safe.

Be Safe, not Sorry.

Photo by Daniel Cheung on Unsplash