Virtual network support

I've noticed that Power Platform Virtual Network support is now GA. This means you no longer need an on-premises gateway (About on-premises gateways - Power Platform | Microsoft Learn) to establish a secure connection using private endpoints to your Azure PaaS services. That’s a cost saver since you don’t need to run a separate machine (VM) for this anymore. Plus, this solution scales much better.

Currently, Virtual Network support is available in the following ways:

• Via full-code Dataverse plug-ins
• Through several low-code connectors that natively support this, including Azure SQL, Azure Queue, Azure Key Vault, Azure File Storage, and HTTP with Entra ID (preauthorized)
• Using Custom Connectors (a powerful option, as it allows you to call any web API within your VNet)

I’ve tested the Azure SQL, Key Vault, and Custom Connector setups. Of course, before anything works, you first need to configure VNet integration within your tenant (Azure + Power Platform). The best way to do this is by following the official documentation: Set up Virtual Network support for Power Platform - Power Platform | Microsoft Learn.

The basic setup steps are:

• Setting up your VNet and subnets (important: you need two subnets—one primary and one failover)
• Provisioning Azure policies and configuring permissions
• Assigning the subnet injection policy to your Power Platform environment(s)

In most cases, you’ll want to integrate with existing resources in another VNet. To make this work, you can use VNet peering (Azure Virtual Network peering | Microsoft Learn).

Also, don't forget to configure your DNS! In my case, I used a private DNS zone and linked it to the VNets. This ensures proper name resolution for your private endpoints, preventing connectivity issues.

Azure SQL Server

The first test with Azure SQL Server (Azure SQL Database | Microsoft Azure ): To check whether we can connect only through the Power Platform environment with VNet integration, I first completely locked down the firewall. This ensures that no connections are allowed.

When we then try to connect using Power Automate, we start getting timeouts and retries. This indicates that the connection isn't going through, due to the missing VNET configuration in Azure.

Next, we configure Azure SQL with the correct networking settings by adding the virtual network. This ensures that the database is accessible only through the designated Power Platform environment while keeping it secure from external access.

Then, we trigger the flow again—this time, everything works as expected! The connection goes through smoothly via the Power Platform environment with VNet integration, confirming that the setup is correct. 🎉

I also test the connection through a Power Apps Canvas App, and it works perfectly! The app successfully retrieves data via the VNet-integrated connection.

Azure Key Vault

Next up is Key Vault. First, we completely lock it down, ensuring that no external access is allowed.

Then, we trigger the flow to see if it can access Key Vault. As expected, since the vault is locked down, the request fails. We’re seeing an "403" message, which isn’t what we expected exactly 🤔, but the result is the same..  

Now, we add the VNet to the Key Vault, ensuring that it allows access only from the configured Power Platform environment.

I can't access the Key Vault via my own client anymore

But via the flow I can access the Key Vault and the secret.

Custom Connector

Finally, I tested the Custom Connector (Create a custom connector from scratch | Microsoft Learn ), which calls a Logic App via a private endpoint. For this to work, you must use a Logic App Standard Plan—otherwise, VNet integration won’t be available. This setup ensures that the Logic App remains securely accessible only within the private network. 🔒✅

I created the Custom Connector using a Postman collection export. In the connector's definition, we can see the URL pointing to the Logic App trigger. We then call this endpoint with the correct query parameters, ensuring that the request is properly formatted🚀.

Now, when we call the Custom Connector via a Power Automate flow, we successfully receive a response! 🎉 This confirms that the Logic App private endpoint is correctly configured, and the request flows securely through the VNet integration without any external exposure. ✅

 The Logic app

Conclusion

With Power Platform Virtual Network support, we’ve successfully secured our integrations while maintaining seamless connectivity. By configuring Azure SQL, Key Vault, and Logic Apps with private endpoints, we ensured that all communication happens strictly within our VNet, eliminating the need for an on-premises gateway.
✅ Better security – No exposure to public networks
✅ Cost savings – No need for a separate VM to run a gateway
✅ Improved scalability – A more efficient and flexible solution