Power Platform virtual network support: the pre-flight checklist for regions, subnets and delegation

Power Platform virtual network support lets Dataverse plug-ins and a set of connectors reach resources that aren't on the internet: an Azure SQL database behind a private endpoint, a Key Vault with public access off, an API inside your own network. It works by subnet delegation: you hand Power Platform a subnet in each of two Azure regions, and the containers that run your plug-ins and connector calls get their addresses from it. Most of the setup is fixed once you've done it, because you can't resize the subnet or change the network's DNS while an environment uses it. So the time to get it right is before you link the first environment. This checklist covers what to settle first, in the order the problems tend to appear.

Pause animation

1. 1Plug-in or connector runs in a Power Platform container
2. 2The container gets an address from your delegated subnet
3. 3Your DNS and network rules apply
4. 4The call reaches the private endpoint inside your network

1. The environment qualifies

• Managed Environment. Microsoft's setup page requires it. Turn it on for each environment first.
• Environment type. Production, Default, Sandbox and Developer environments are supported; Trial and Dataverse for Teams aren't.
• Azure subscription. You need one in the same tenant, to hold the virtual networks and the enterprise policy that links them to the environment. Register the Microsoft.Network and Microsoft.PowerPlatform resource providers in it.
• Roles. Someone with network rights in Azure (Network Contributor or equivalent) creates the networks and the policy; a Power Platform administrator links the policy to environments. If they're different people, give the Power Platform administrator read access to the policy.
• US Government. Only GCC High and DoD are supported, not GCC.

2. Two networks in the paired regions

The delegated subnets must sit in the Azure regions that match the environment's Power Platform region, and where the geography has two, you need one network in each, for failover. This applies to non-production environments too. Some examples:

The diagnostics PowerShell module's Get-EnvironmentRegion tells you the exact region an environment lives in; where a geography offers more than one pair, use the pair that matches it. If the resources you want to reach are in another region, keep the delegated networks where Power Platform needs them and peer them to the network the resources are in.

3. Size the subnet for its future

You can't change a delegated subnet's address range while an environment uses it; changing it breaks the delegation and the environment stops working. Size it once, generously.

Worked examples from Microsoft: four production environments sharing a policy need 4 × 30 + 5 = 125 addresses, a /25; twenty developer and sandbox environments need 20 × 10 + 5 = 205, a /24. Usage starts at four containers per environment and normally stays between 10 and 30 as calls scale. Where you have two subnets (two regions), both must have the same number of available addresses.

Other subnet rules:

• The subnet is dedicated: delegate a new subnet to Microsoft.PowerPlatform/enterprisePolicies and use it for nothing else. An existing network is fine; an existing busy subnet isn't.
• One subnet belongs to one enterprise policy. One policy can serve several environments, except that early release cycle environments need their own.
• If you do need to resize later, Learn's pages differ: the setup page says to contact Microsoft Support, and the overview says to turn subnet injection off (Disable-SubnetInjection), change the range, and turn it back on. Either way it's an outage, so plan for it.

4. What runs through the subnet

Once an environment is linked, these make their calls from your subnet:

And the exceptions to plan around:

• Power BI and dataflows don't use this; they use a virtual network data gateway.
• Low-code plug-ins that use connectors aren't supported until those connectors move to subnet delegation.
• Azure-aware plug-ins don't support it.
• SQL Server through an on-premises data gateway isn't supported in a linked environment; move those connections to the private path.
• Certificates. An endpoint inside your network must present a TLS certificate whose full chain leads to a well-known root authority; a private root CA isn't accepted.

5. Decide how calls to the internet behave

After delegation, plug-ins and connectors can still reach internet addresses by default. They break when your network blocks them: a firewall, a route that sends 0.0.0.0/0 to an appliance, or a network security group. Microsoft's guidance is to put a NAT Gateway on the delegated subnet so outbound traffic leaves from addresses you own and control, and to review plug-in code and connections before you switch on, pointing them at private endpoints where the target is in Azure. An ISV plug-in that calls its vendor's API needs that address allowed through your firewall.

DNS is the other fixed setting. Power Platform resolves names with the DNS servers configured on the network that holds the delegated subnet, so a private endpoint's name resolves privately only if that network is linked to the private DNS zone or forwards to something that is; the private endpoint DNS guide walks the checks. You can't change the network's DNS servers while it's in use either: unlink the environments, change it, wait 30 minutes, then link them again.

6. Switch on in a quiet hour

Enabling or disabling subnet delegation can mean up to 30 minutes of unavailability or instability while connections start up in the new subnet. Link the policy outside working hours, then check the environment's History in the Power Platform admin center shows Succeeded. An enterprise policy can only be removed from an environment with PowerShell (Disable-SubnetInjection), so keep the module to hand.

For Key Vault behind a private endpoint, put the endpoint in the same region as the environment, in the delegated network, in each region the policy covers. That's the step people miss when an environment variable can't read its secret.

Sources

• Microsoft Azure VNet support overview, Microsoft Learn (subnet sizing, supported services, environments and regions, internet-bound calls, DNS, the FAQ)
• Set up virtual network support for Power Platform, Microsoft Learn (Managed Environments, roles, resource providers, two regions, the 30-minute disruption, linking and unlinking the policy)
• Virtual Network support white paper, Microsoft Learn (integration patterns, NAT Gateway, data gateways for ETL)
• Troubleshoot Virtual Network issues, Microsoft Learn (the diagnostics module)
• "User is not authorized to read secrets" error when saving environment variables, Microsoft Learn (Key Vault private endpoints in each region)