While the Power platform continues to grow, both in features and popularity, it’s not all as peachy as the Microsoft marketing folks would have you believe. Many governance issues, such as the inability to block users from using say Flow (now Power Automate), or limit them in terms of which particular connectors can be leveraged have been repeatedly brought and discussed. Not to mention the ill-fated attempt to shove yet another self-service “feature” down our throats.
Now, Microsoft is finally starting to address some of the issues mentioned above, namely the lack of control we had when it comes to deciding which connectors can and should be used within the organization. Up until recently, we were only able to designate a connector as either “business data only” or “no business data allowed”, and impose some control in situations where more than one connectors was used and data crossed the “business” boundary. Might sound good in theory, but in practice didn’t address many important scenarios, such as the one detailed in this article, as those policies only affected flows with more than one connector.
With the advent of the new, unified Power Platform Admin Center, the Data policies functionality has been expanded to include another “group” for the classification of connectors, namely “blocked”. Putting a connector in the Blocked group effectively prevents users from using it in flows and Power apps, addressing the bulk of scenarios that people were worried about. And, you can select Blocked as the default group, in which case any newly added connector will need to be approved for use first. Note that this does not affect any existing connectors, so you will have to reclassify those manually.
The controls that enable this functionality are only available in the new Power Platform admin center and not in the individual Flow or PowerApps ones. So if you want to start using them, head to this direct link to access the portal: https://admin.powerplatform.microsoft.com/. Then, on the left nav pane, hit the Data policies (preview) item then use the New policy button (or edit an existing policy). This will bring up the familiar wizard interface you might have seen in other parts of Office 365, which will guide you through the process. On the first page, enter a name for the policy and then move to the Connectors page. Here, you will get a list of all the connectors available across your environments. In my case, this amounts to 343. On this page you will also find the button to Set default policy, which brings the dialog shown above.
To move a given connector to the Blocked group (or to the Business one for that matter), hit the button on top or select the corresponding entry from the three vertical dots menu. Here’s the bad news – while you can select the top column checkbox to select them all, you cannot use this method to bulk move all connectors. The reason being, Microsoft has decided to prevent you from blocking certain first-party connectors. Those include things like Bing Maps (?), the SharePoint, OneDrive and OneDrive for Business connectors, the Office 365 Outlook and Outlook.com connectors, and a dozen others. And what’s more surprising – even some third-party connectors (“Cloud PKI management”) cannot be blocked?! Such connectors will be designated with “No” in the Blockable column.
This in turn means that if you want to properly secure your environments(s), you are in for a lengthy process of selecting connectors and moving them to the blocked group. And even then, some connectors will still remain unblockable, and accessible to end users. This will also apply to any newly released connector that is classified as “unblockable”. So overall, Microsoft gets “A” for effort, “C” for execution.
Anyway, once you have decided which connectors to block or move to another group, hit the corresponding button on top and then proceed to the next page, Scope. Here you will define to which environments the current policy applies. Adjust your selection as necessary, then proceed to the next page where you will review the configuration and if everything checks out, create the policy.
Policies go into effect almost immediately, but a deliberate decision has been made to not hide connectors you have designated as blocked from the UI. Users can still select and use those in their flows/apps, however when they hit the Save button, a tooltip will be shown on top, resembling the following:
Your flow was updated, but it is currently suspended since it uses a combination of connectors that conflict with the company data loss prevention policies or billing restrictions.
In effect, the Flow is now in Suspended state and any sort of Run functionality will be disabled. There doesn’t seem to be a single place from which you can get a list of all such flows within your organization, the only thing that comes close is the “resources” page in the old Flow admin center, which doesn’t show any information on why the flow was disabled. Hopefully improvements are coming in this area as well.
So that’s it, in a nutshell. The new Block controls are nice to have, but should be expanded to cover every available connector, or even better, should be configurable down to the individual action/trigger. Some better inventory functionality should be made available as well. Still, the new controls are a step in the right direction, and I hope Microsoft will expand on these in the future.
I understand your perspective, in terms of the need for admins, and more generally businesses, from taking appropriate steps to secure their business or institution. In this post, or your comments about Team Connectors, you represent that point of view.
However, I think it’s fair to point out that there should be a clear reason for removing access to a given connector, whether it’s in Power Automate or Teams, or elsewhere.
What security issue(s) have you identified that are left unaddressed by Microsoft’s policy? I am not saying there are none, I am saying if you advocate for more granular control, it’s reasonable to ask – to what end? Or at least mentioned one or more security challenges this policy will cause.
If an end user who wants to legitimately improve a process, to positively impact his/her organization by taking the initiative to try something new – automate a process, create a more consistent and reliably accurate workflow, or to make their client’s perception of ease of doing business better, be careful about shutting that down without cause.
No doubt security is an important consideration, to understate the issue. But it’s always been true it’s a balancing act against making technology useful and easily adopted. Sometimes, I work with clients who clearly wish to return to days gone by where complete and total control was possible.
My point is not to say – you are wrong! – and make the issue black & white. It’s just to say, grass roots digital transformation has real value, and it’s very quickly snuffed out when users make an effort to improve a process, and hit roadblocks. One or two times, and that use probably is done trying, and that has a cost too.
The reason is detailed in the P365 article I linked to in the post – in a nutshell, Flow allowing end users to forward their messages to any email address, and by doing so bypass any restrictions configured by admins. Which can also easily be exploited by bad actors as well.
And btw, the restrictions detailed in the article at hand don’t prevent this (thus “some” in the title).