Teams Real Simple with Pictures: Using Data Loss Prevention (DLP) to stop data leakage from Dataverse for Teams Apps such as Bulletins or Employee Ideas

This blog is part of a series on Teams. For more articles, check back often

Written: 21/03/2021 | Updated: N/A

Last month, I wrote a bit about the new Power Apps Templates in Teams – Bulletins and Employee Ideas. I really liked them. They are really useful for bringing in new functionality for Teams and filling some gaps, they can be used by both users inside the Team where they are deployed or outside of the Teams via the broad distribution functionality. They can be extended by developers looking to build on the functionality which already exists. However, in thinking about how these apps can be extended we must also put our security and compliance hats on and think about how the ability to extend them can be controlled – particularly in terms of connectors and data leakage. You see, when we start using these apps we will begin adding data – company data. In the case of bulletins we add things like company news, URL’s and even contact details. In the case of employee ideas we add ideas about how the company may improve and these ideas could – for example – be based on company data or expose where the company is lacking. Whilst we like to believe that everyone who has access to modify these apps have the best of intentions, it is too big a risk to simply assume that data will never be exposed – accidentally or maliciously via connectors to places where it shouldn’t be seen to audiences who should not see it. A good example is Twitter. Our data makes it onto Twitter it could seriously damage our brand and we could be facing some legal consequences

So when we deploy the apps into Dataverse for Teams, it’s really quite important to think about setting up Data Loss Prevention (DLP) on the environments which are created when we deploy the apps. It doesn’t take long and is really worth it to proactively prevent data leakage in the future. There’s some good governance upside too

This blog will cover

  • Setting up a DLP Policy on the Environments the Apps are deployed to
  • Modifying the DLP Policy
  • Removing the DLP Policy
  • Deploying other apps and flows in the future


  • Environment Admin Permissions or Global Admin Permissions to spin up the DLP Policy
  • Teams/Power Apps/Power Automate Licence to test (Usually within Microsoft 365 Subscription


1.) So lets begin. Bulletins and Employee Ideas are deployed into two Teams within Microsoft Teams. Bulletins is deployed in a Team called Bulletins 2 and Employee Ideas is deployed in a Team called Employee Ideas

2.) Log into In this example you can see that there are corresponding environments for Bulletins 2 and Employee Ideas which were created when the apps were deployed. These are the two environments which will ultimately be protected by a DLP policy

3.) From the left menu, select Data Policies

4.) Select New Policy

5.) Name the policy and select Next

6.) Now there are three groups (buckets) which connectors can be assigned to

  • Business: Connectors for business sensitive data. Connectors in this bucket cannot share data with any other group
  • Non Business: Connectors for non-business data, such as personal use data. Connectors in this group can’t share data with connectors in other groups
  • Blocked: Blocked Connectors cannot be used at all in environments where the DLP Policy is applied

7.) If it is a case of simply wishing to block specific connectors from being used in the environment and within the apps and flows which are deployed in them, search for the connector, select it and then select block at the top. Repeat this for all the connectors which need to be blocked. After doing this for the required connectors, select the blocked group to review them and if happy, select Next

8.) If you want to go one step further – completely restrict the connectors the apps deployed in the environments use so they cannot share data and interact with any other connectors in any other group then return to the non-business group, search for and select all the connectors which the apps use, and select Move to Business. Repeat this for all the connectors which the deployed apps such as Bulletins or Employee Ideas use. After doing this for several connectors, select the Business bucket to review them and if happy, select Next

Before the next step you may naturally ask – how do I actually find the connectors the apps such as Bulletins and Employee Ideas use? In Teams, select Power Apps then select the tab Build. Select the Environment, then select the App. When the app has opened in Power Apps Studio, select Data then Add Data and you can see a list of the connectors the app uses. Do this for each app (for example Bulletins has 2 apps and Employee Ideas has 2 apps)

9.) Once our connectors have been sorted into groups, define the scope of the DLP policy. This can be tenant wide, adding all environments or excluding others – however in this example we are applying the DLP policy to the two specific environments which correspond to Bulletins and Employee Ideas. Select Add Multiple Environments and then Next

10.) Select the Environments then select Add to Policy at the top

11.) Select Next

12.) Review and once complete select Create Policy

13.) The DLP Policy has been created

Our job here is done

A quick test to see that the implementation was successful. I dive into Power Apps Studio within Teams and try adding a Twitter connector to the Employee Ideas app. It throws an error saying that it conflicts with the Data Loss Prevention Policy



1.) In the Power Platform Admin Centre select Data Policies, select the DLP Policy and then Edit Policy

2.) The wizard will rerun where

  • The name of the DLP Policy can be changed
  • The connectors can be reallocated into their respective groups
  • The scope of the policy can be changed and environments added/removed


1.) In the Power Platform Admin Centre select Data Policies, select the DLP Policy and then Delete Policy

This image has an empty alt attribute; its file name is image-132.png

2.) Select Delete to confirm


When applying the DLP Policy to the environments, the biggest thing to be mindful of is other apps and flows which may potentially be deployed into those environments in the future. For example, if I try to build this simple flow in the Employee Ideas environment I cannot save it as it says the action violates the org’s data loss prevention policy. This is because the YouTube connector was in the blocked list in the DLP policy as illustrated above

So when applying the DLP policy it is probably a good idea to liaise with those who are making apps and flows in your organisation in the future to ensure that the right connectors are sanctioned and grouped with other connectors for which they will be used. Needless to say, it’s a great control mechanism – for general use of connectors in environments, or connectors which need to be added to extend app functionality. It’s a great way to prevent data being leaked when using apps such as Bulletins or Employee Ideas, or even flows, within Dataverse for Teams

2 thoughts on “Teams Real Simple with Pictures: Using Data Loss Prevention (DLP) to stop data leakage from Dataverse for Teams Apps such as Bulletins or Employee Ideas

Comments are closed.