Connectors are the lifeblood of Power Platform activity. They allow our apps, flows, bots and reports to talk to and show data from many different services. Whether you’re a Power Platform admin, consultant, developer or business decision maker, it’s important to understand the good, bad and ugly when it comes to connectors. Power Platform DLP involves aligning connectors to specific categories to enable safe passage for makers.
In order to get a solid DLP baseline policy in place, first we need to understand existing connector usage. This article will walk through some good methods to undertake a usage review and plan for DLP.
As explained in the Microsoft documentation here, a connector is a wrapper around an API. We can use these API’s to talk to data in our apps and flows. You don’t have to write any code to use these API’s, they’re built for you with nice drag-and-drop mechanics. All you have to do then is add the parameters needed to make a successful call.
To visualise this, we can take a look at a Power Automate action. In the image below the API call is the ‘Get items from a SharePoint list’ action (boxed pink), the parameters it needs to make the successful call are then listed (boxed green):
Behind the scenes, the actual code to make the API call is built for you. A pro developer would probably have to write this manually, from scratch:
That’s why the Power Platform can be so accessible to those less familiar with code. That’s also why Power Platform DLP is essential to all organisations, because it’s so easy.
License-wise, connectors come in two forms – standard and premium. Standard connectors are free for anyone to use, premium ones require licensing. If your app or flow uses standard and premium connectors, you’ll need licensing. Both standard and premium connectors could also have additional charges or subscription costs associated. I’ll cover this in more detail later in this article.
At time of writing, there’s over 1,000 connectors that can be used out-of-the-box in the Power Platform. If there isn’t a connector we need, we can build our own so long as the service has an available API endpoint to call. These are known as custom connectors and can be used in apps & flows in exactly the same way. Every connector has two key properties – triggers and actions.
Triggers
A trigger is an event that has to happen for subsequent action(s) to then be performed. Triggers can’t be used in Power Apps, they’re Power Automate focused.
Example: In a 100m race, the trigger is the starting pistol being fired.
Actions
Actions are what you want to automate once the process is triggered. You can have a variety of actions covering multiple connectors.
Example: In a 100m race, once the starting pistol has fired (the trigger), sprinters will perform multiple actions; spring from the blocks, gain momentum, increase stride length, run really fast and duck their head at the line.
Connector analysis; who's using what
To review what connectors are being used in the Power Platform in your tenant, you ideally need the Centre of Excellent (CoE) Starter Kit up and running. Even if your company isn’t going to invest in premium licensing for the masses, I highly recommend you get what you need to run the CoE kit in its own dedicated environment.
This is important, as the kit comes with a thorough Power BI dashboard. There are dedicated pages to review usage of connectors across your Power Platform estate. At time of writing, these are the pages of interest to focus on:
These pages in particular have configurable filters. All environments are important to monitor of course, ESPECIALLY if you don’t have DLP in place already. However, the most likely place for immediate focus will be the default Power Platform environment. This environment can’t be restricted or deleted, everyone has access to build apps & flows right away. The Power BI dashboard filters can help us to focus in on specific environment(s):
This will give you a great starting point to understand what connectors are being used. You can click on the bar for a connector to filter the information further. It’s great to be able to see what assets use what connector(s) and who built them:
That’s all well and good, but understanding the data you’re looking at is of huge importance. Let’s look into some common things I’ve found when reviewing connector usage.
Connector reviews
If you’re doing one of these for the first time, it might take a while. There could be some obvious connectors you’ll see that you know are ok, such as SharePoint or Office 365 Users. But there’ll also be some that you a) know will ring alarm bells, b) aren’t sure about so need to research or c) gloss over as you’ll assume they’re ok.
The first step to a good connector review – the connector reference overview. This gives amazing insight for every single connector available in the Power Platform.
TIP: Bookmark that link. I’ve used it most days for the past few years, it’s invaluable and routinely updated. It’s your connector bible.
It’s super easy to find any connector you need using the filter box. Each connector has a dedicated page and will cover things like:
1- Whether it’s in Preview; preview connectors aren’t recommended for Production apps/flows.
2- License implications.
3- Known limitations (if any and/or known).
4- Throttling limits; how many times can your process call the connector in a given timeframe.
5- How to use the connector; what triggers and/or actions does it have.
Some connectors will have more information than others, so it pays to read them carefully.
With that in mind, let’s dive into some connector reviews!
Mail connectors
There are lots of connectors available to automate the sending of email notifications. It’s very common in a Default environment connector review to see these four pop up, but what’s the difference?
If your company is Microsoft 365 focused, it should be easy to discount the Gmail connector. If there’s a specific business reason for using it (as with any non-Microsoft connector), you may need to think about creating a new Power Platform environment solely for using this connector. It will need its own DLP policy that allows use of Gmail. Most of the time from my experience, the majority of Gmail activity is forwarding business-related emails to personal accounts. This is dangerous if their business email receives sensitive information, either in the body or as attachments. Simply put, eliminate the risk.
I’ve seen the Mail connector used LOADS. It’s easy to see why from a maker perspective; go and add a new action to a flow and search for ’email’, see what appears first:
Who doesn’t click on the first search result when using Google or Bing? It’s an easy thing for makers to do. However, looking at the connector information, there are some warning signs:
1- Not meant to be used in high risk scenarios, recommends using other mail connectors.
2- Uses an IP that can have a bad reputation.
3- Restricted for new tenants.
4- Reduced throttling limit due to reports of being used for spam.
Meanwhile, the Outlook.com connector is another one unknowingly used in the Power Platform. Authorisation for this connector comes from a maker’s personal email address and password, not their business one. You could maybe argue that someone wants to automate parts of their personal mailbox. I’d recommend they get a personal tenant in this case.
The Office 365 Outlook connector is highly likely to be your default for automating email transactions in apps and flows. Authorisation for the connector is bound to the makers business email address, which is tied to the workplace Global Address List (GAL)/Active Directory. You can also use Service Account credentials for the same reasons.
Power Platform DLP recommendation:
Allow Office 365 Outlook connector.
Block everything else mail related.
OneDrive connectors
This can sometimes catch people out. The OneDrive connector is similar to the Outlook.com connector; you’ll authorise the connector with a personal account – not a business one. The correct one for business use will be the OneDrive for Business connector. Your average maker is unlikely to know this so directing them with the right DLP alignment is essential.
Power Platform DLP recommendation:
Allow OneDrive for Business.
Block OneDrive.
Excel connectors
Same again here, there’s 2 Excel connectors; one uses a personal email to authenticate and the other a business email. As with Outlook and OneDrive, the Excel ones both have the same logo. It’s easy to see why it might catch people out. In this instance, the Excel Online (OneDrive) connector is the one using personal, Excel Online (Business) is the one you want.
Power Platform DLP recommendation:
Allow Excel Online (Business).
Block Excel Online (OneDrive).
Anything file or data storage related
There are a LOT of file services you can connect via the Power Platform. I can’t list them all (mostly because I can’t remember every one) but connectors that spring to mind:
1- SharePoint Online
2- OneDrive for Business
3- Google Calendar
4- Google Drive
5- Google Sheets
6- Dropbox
7- Box
8- FTP
9- InfoQuery
There are several considerations for using data services; Has it been officially procured by your organisation for wider use? Where in the world is the data processed and does it meet relevant legislation(s)? Is it encrypted at rest? Is it secure? Do you need a Data Sharing Agreement? What happens if it gets hacked? What’s the support like if things go wrong? Is it supported & trusted by our internal Service Desk team?
Did you catch the first post in this Power Platform DLP series? You may remember the example of how file storage connectors can be abused to move or copy sensitive business data. So there are lots of alarm bells for using most file/data connectors that are not directly aligned with your business usage policy.
Power Platform DLP recommendation:
Allow SharePoint Online and OneDrive for Business.
Block everything else that’s not been officially procured for use by your business.
Anything project or task related
For very similar reasons as above, there are lots of project or task based connectors to use. Planner, Trello, JIRA, Azure DevOps to name a few. Again, it’s worth considering the same points around where data is stored, encryption at rest, potential storage of sensitive or personally identifiable information etc.
Power Platform DLP recommendation:
Allow the connector(s) that are officially procured for use by your business.
Block everything else.
Freemium connectors
Earlier in this article I mentioned that connectors come in two flavours – standard and premium. From a Power Platform licensing perspective that’s very true. From a DLP perspective, there’s an additional layer you need to be aware of. I call this layer ‘freemium connectors’.
One of many examples is from a company called Plumsail. They have a range of products to extend native SharePoint Online functionality in Power Automate. According to the connector bible, the Plumsail SP connector is a standard connector for Power Apps and Power Automate, meaning no license required:
However, to use this connector and its actions, you need to purchase an API key from Plumsail directly. You then may have additional charges based on how many API calls you do with that service. It pays to read the documentation for any connector to make sure you’re aware of these charges before the business commits. Similarly, there are premium connectors that also incur additional third party charging/subscriptions. Double whammy.
Another issue I’ve found with freemium connectors – they’re great for shadow IT. Here’s something I’ve seen quite a lot:
1- Staff member logs a ticket to request procurement buy some Plumsail products. The business case is strong as it’ll provide departmental value.
2- Ticket rejected, there’s no IT budget left to procedure the subscriptions required.
3- Staff member talks to Line Manager. They decide to fund out of their own departmental budget instead.
4- Department gets Plumsail products. Everyone is happy, cake is bought into the office to celebrate.
5- Staff member spots the Plumsail SP connector in Power Automate. They already have a license and account, so are free to use the connector. More happy days, more cake is brought into the office.
If Power Platform DLP isn’t in place, the shadow IT scenario is a lot harder to unpick. By default, freemium connectors should really be blocked in your DLP policy. Allowances can be made on a case-by-case basis, or if it’s a widely supported and agreed connector. You may need to consider ringfencing such activities into department-specific environments with a dedicated DLP policy assigned.
Power Platform DLP recommendation:
Allow only the ‘freemium’ connectors officially procured for business use.
Block everything else or deal with on a case-by-case basis.
Logic flows
In the App Connections page of the CoE Power BI report, you might notice a connector called Logic flows:
However, there’s nothing in the Connection References documentation for it. If you google ‘Logic flows’ the top result is this page, but clicking on ‘See documentation’ will give you a nice juicy 404 error. This also isn’t to be confused with ‘Logic Apps‘ which is different, so what is ‘Logic flows’?
Have you got any Power Apps that call at least one Power Automate flow directly within the app? If you do, the Logic flows connector will be created.
It does not appear when creating Power Platform DLP policies, so you can’t block it.
The first time I undertook a connector review, it took me AGES to figure this out. Hopefully I’ve saved you some headaches!
This has been a collection of my go-to knowledge for reviewing connectors. It helps to better plan Power Platform DLP policies – especially if lots of activity has taken place already prior to DLP deployment.
Chances are we can’t just jump in and implement a policy though, that’ll anger a LOT of people when their stuff stops working without warning. In the next article of the series, I’ll walk through a process to run an impact assessment for any proposed DLP policy. This is another critical step before making Power Platform DLP live in your tenant.
If you liked this article and want more epic Power Platform stuff to land in your inbox every week, don’t forget to subscribe 😊
Another useful article and I sure did pick up a few new things here. Didn’t know about “Logic Flows” and the “Connector reference” documentation. Thanks for sharing.
Thanks Douglas, glad the article was of use. Hopefully the other blogs in this series will be of as much help.
Agreed, thats a great tip
Many Thanks for Sharing
Hi Criag
nice article. But can you help me to understand why we should block freemium license connector in the tenant ??
Please explain in more simple words.
Thanks for your efforts.
Hi Shub,
Good question, simply put it’s to prevent usage of connectors that require addition non-Microsoft paid-for subscriptions. In these circumstances, only allow freemium connectors where the business or department have agreed to procure that additional service, ie Encodian or Adobe PDF, or agree to stay within the free usage limits.
Hi Craig, another great article that has helped me out!
My organisation is nervous about opening up the OneDrive for Business app in case someone moves documents into another organisation’s OneDrive. Is this possible, and if so, how can it be restricted?
Hi Dave, great question! Yes, if you have credentials to x2 OneDrive For Business instances then you could build a flow to move documents, for example I have my ODfB with my work account and have one with my personal tenant too.
The best way to prevent this I believe is to turn on tenant isolation. I’ve done an article about it as part of my DLP series which might help?