Power Platform Advanced Connector Policies
By Craig White
Anyone following my blog since it started will know I like a bit of Power Platform DLP (Data Loss Prevention). This is administrative controls to allow what connectors we can & can’t use in our apps, flows and agents. It’s great that my experience here continues to help others.
With Power Platform Managed Environments, we’re able to take this up a notch with Advanced Connector Policies.
The differences to standard Data Policies are quite powerful, but are they enough to move away from the OG? Let’s find out.
There are a couple of ways to access Advanced Connector Policies in the Power Platform Admin Centre:
1- PPAC > Environment Groups > select an environment group > Rules
2- PPAC > Security > Data and Privacy. This is the same route we take to find the original Data Policy option.
Create an Advanced Connector Policy
Either method of access will result in the following experience. By default, 24 connectors will be in the Allow list with the rest blocked. This initial list of allowed connectors are the ones listed as unblockable connectors for standard Data Policies:
To add a connector, select the Add Connectors option. Find the connector(s), select then click Add Connectors. These will then move to the Allow list.
To remove / block a connector, simply select the connector(s) and click the Remove Connector option:
To edit what triggers and actions to allow or block, select the connector and click Edit actions. You can only do this for one connector at a time. Don’t forget to save once configured:
Once you have saved your Advanced Connector Policies, you’ll need to publish them for changes to take effect:
Why use them over the standard Data Policies?
There’s a couple of really good use cases for wanting to use Advanced Connector Policies:
No more Non-Business category
In a standard data policy, we must align a connector to Business, Non-Business or blocked. This determines whether we can use the connector and if so, what other connector(s) it can be used with, or blocked entirely from use.
Working extensively with customers for 5+ years, no-one really gets nor finds an amazing use case for using the Non-Business category. It’s normally a case of use it or block it, and remove any grey area. Advanced Connector Policies seems in line with what most have been thinking.
Block unblockable connectors
In a standard data policy, there are a handful of connectors we cannot block. These are mostly Microsoft services that would be commonly used in our apps, flows and agents – such as SharePoint, Dataverse and Office 365 Users.
In Advanced Connector Policies, we can block these. What I like most about this isn’t the power to block SharePoint or Dataverse – but block connectors that make no sense being unblockable. Looking at you, Skype for Business. It always irritates me having to allow this connector, given there’s zero business reason to allow it; support for most SfB services expired in October 2025.
Granular control of triggers and actions
Following on from the point above, Advanced Connector Policies allow granular control of triggers and actions for both blockable AND unblockable connectors. This is something we can’t do with unblockable connectors in a standard DLP policy.
Examples of this include blocking the Dataverse MCP server from agents (if that’s your wish), or removing all deprecated actions from the Office 365 Outlook connector. One of my favourites to remove is any of the ‘from a selected environment’ actions in the Dataverse connector, or removing anything that’s preview or deprecated:
New connectors automatically blocked
This is a nice quality-of-life feature – any new connectors are instantly added to the Blocked list. No fear that something has accidentally slipped through the net and being used in dodgy ways.
Of course, you can enable the same behaviour in a standard data policy – but you must manually configure each time. We do this by changing the default group – something that can be easy to forget.
They play nicely with original Data Policies
Well, they do eventually. As you would expect, your environments will reference any Data Policies and Advanced Connector Policies for connector management. This is known as Data Policy mixed mode, as referenced here.
However, behaviour when using both can vary, which leads us on nicely to…
Why you shouldn't use them over standard Data Policies
There is still a way to go before Advanced Connector Policies are the preferred option for Power Platform connector governance.
Standard Data Policies are still quicker to take effect
Whilst a standard data policy and ACP should work in tandem, it can take a while to see that in action.
In my testing, I applied a standard Data Policy to an environment to block a connector. The impact was instant, not allowing me to add a blocked connector to a flow:
Adding some slightly different configuration to the same environment using an Advanced Connector Policy worked, but took several hours to take effect. Perhaps not the best experience or inspiring confidence.
You can to some extent track the change (PPAC > Manage > select environment > History). Below I updated and published an ACP rule to the Environment Group governing the environment. The log isn’t granular but does track date/time:
2 hours after that change, I could still build a flow using a connector I’d blocked. I had to wait until the following morning to finally see it working:
Maybe this could be a timing or data centre issue, but something to keep in mind.
As we can see from the above, error messages presented to the user are inconsistent too. A block caused by a standard Data Policy yields a cleaner message, even stating the Policy name that’s providing the block. This is going to be easy to send to IT Support to help unblock.
The message presented via an Advanced Connector Policy block is less user-friendly. Hopefully Microsoft can iron this out whilst it’s still in Preview.
Connector disparity
During prep for this post, I noticed a difference in the number of connectors available to block in both policy methods.
A standard Data Policy has a higher number available to configure compared to Advanced Connector Policies (1,633 vs 1,281 at time of writing):
In the documentation, it states that Advanced Connector Policies only covers certified connectors. I’m not really sure what that means as, I thought, if the connector is available to use in the Power Platform, then it’s been certified for use?
What I have worked out so far (either with my own eyes or those in the Power Platform Admins Assemble WhatsApp group), the following are part of the missing numbers:
- Power Automate Desktop connectors
- The original Copilot Studio connectors
- Some of the Independent Publisher connectors – but not all
- No HTTP or When a HTTP Request is Received
Which leads me onto the next point:
No custom connector or endpoint filtering
In a standard policy, we’re able to configure the HTTP connector to allow or block specific endpoints (aka custom API’s). We’re also able to do the same for custom connectors.
This is not currently possible with Advanced Connector Policies; there’s simply no option for managing custom connectors at all. Without the presence of the HTTP connector, we can’t manage endpoints this way either.
This has an added knock-on for governing agents; custom MCP servers and using Agent2Agent adds a custom connector under the hood. If you want granular control of these, you’ll need to use a standard Data Policy.
No granular controls for MCP Server connectors
The Dataverse MCP Server action is part of the Dataverse connector. In an Advanced Connector Policy, we can allow or block it, but we can’t go a level deeper to allow or block what it can do when an agent uses it.
Currently, the only way we can do this is within Copilot Studio itself. When adding as a tool to an agent, the default is all actions are selected. Toggle to off to allow more granular control of what the agent can and can’t use.
This is on an agent-by-agent basis currently, there’s no global setting to do this per environment, for example.
INTERNAL connectors are exposed
I’m still trying to work out what these are, and what the impact is if they’re blocked.
As you can see from the example below for the SharePoint connector, there are 2 ‘Create item’ options. What is the [INTERNAL] one and what’s the impact if it’s blocked?
Something I’m still testing and will update this post when I’ve found out more. Other connectors have these ‘internal’ actions too, such as Dataverse and Microsoft Teams.
Still in preview
Already mentioned earlier in the article and mentioned in the documentation: at time of writing, Advanced Connector Policies is a preview feature. Microsoft don’t recommend anything in preview for production use.
Future
Advanced Connector Policies show encouraging signs for how we can manage Power Platform connectors in future. The cleaner and easier implementation, as well as control over any connector (and their triggers/actions) is a big win. Being able to use these against non-managed environments in future will also be a big plus, as hinted in the docs:
That said, if it were to go live tomorrow, standard Data Policies still represent the better option for me; quicker to take effect, full range of connectors, HTTP & custom connector config being the major plus points at present.
Have you played around with Advanced Connector Policies yet? What do you think of them compared to the existing Power Platform DLP policies option?
Thanks for reading. If you liked this article and want to receive more helpful tips about Power Platform / Agent governance, don’t forget to subscribe or follow me on socials 😊
