If you have locked down your Azure Service Bus with network restrictions and then tried to connect Power Automate, you have probably hit a wall. The error is unhelpful, the documentation is misleading, and the obvious fix does not work.
The Problem
Service Bus supports a "trusted Microsoft services" bypass that lets certain Azure services access the namespace even when network rules block everything else. Logic Apps is on the trusted services list. Power Automate is not.
This catches teams off guard because Logic Apps and Power Automate look almost identical from the outside. They share connectors, similar flow designers, and similar capabilities. But Power Automate runs on shared multi-tenant infrastructure, and Microsoft does not include it in the trusted services bypass for Service Bus.
VNet Integration Does Not Help Either
The Power Platform now has a VNet integration feature, but the Service Bus connector is not among the connectors that support it. Even if you have Power Platform VNet integration configured, Service Bus calls from Power Automate still originate from Microsoft's shared infrastructure and get blocked by your network rules.
What Actually Works
The most reliable approach is to route Power Automate traffic through Azure API Management. If you already have APIM deployed inside your VNet, this is straightforward.
APIM sits inside a spoke VNet, its outbound traffic routes through your network infrastructure like everything else, and its egress IP is already allowed on the Service Bus firewall. You expose a thin API layer on APIM that accepts messages from Power Automate (authenticated via subscription keys and Entra ID) and forwards them to Service Bus.
Power Automate calls the APIM endpoint instead of Service Bus directly.
This pattern also works for Logic Apps flows in the same environment, giving you a single, auditable entry point for all Power Platform traffic into the messaging layer. Rate limiting, request validation, and logging come included as part of APIM's standard capabilities.
Other Options
On-premises data gateway. You can install a data gateway on a VM inside your VNet and route Power Automate traffic through it. This works but adds another piece of infrastructure to manage, and the gateway becomes a single point of failure.
Relax network rules. You could allow the Power Platform IP ranges on your Service Bus firewall. Microsoft publishes these ranges, but they change frequently and are shared across all Power Platform tenants globally. Depending on your security posture, this may not be acceptable.
Move to Logic Apps. If the flow does not need Power Automate specifically, rebuilding it as a Logic App (Standard) with VNet integration gives you native access to network-restricted Service Bus. Logic Apps Standard runs on dedicated infrastructure and supports VNet injection.
The Right Choice Depends on What You Already Have
If APIM is already in your architecture, use it. The additional configuration is minimal and the pattern is clean.
If you do not have APIM and the flow is simple, consider whether Logic Apps is a better fit for this specific integration.
If you are running multiple Power Automate flows that need access to network-restricted services, the data gateway approach may be worth the operational overhead.
The one thing to avoid is opening up your Service Bus network rules just to accommodate Power Automate. That undermines the security controls you set up in the first place.
Running into networking issues with Power Platform and Azure services? Get in touch to discuss your architecture.