Virtual Network support for Power Platform overview (preview)

[This article is prerelease documentation and is subject to change.]

With Azure Virtual Network support for Power Platform, you can integrate Power Platform with resources inside your virtual network without exposing them over the public internet. Virtual Network support uses Azure subnet delegation to manage outbound traffic from Power Platform at runtime. Using a delegate avoids the need for protected resources to travel over the internet to integrate with Power Platform. Virtual Network, Dataverse, and Power Platform components can call resources owned by your enterprise inside your network, whether they're hosted in Azure or on-premises, and use plug-ins and connectors to make outbound calls.


  • This is a preview feature.
  • Preview features aren’t meant for production use and may have restricted functionality. These features are available before an official release so that customers can get early access and provide feedback.

Power Platform typically integrates with enterprise resources over public networks. With public networks, enterprise resources must be accessible from a list of Azure IP ranges or service tags, which describe public IP addresses. However, Azure Virtual Network support for Power Platform allows you to use a private network and still integrate with cloud services or services that are hosted inside your enterprise network.

Azure services are protected inside a Virtual Network by private endpoints. You can use Express Route to bring your on-premises resources inside the Virtual Network.

Power Platform uses the Virtual Network and subnets that you delegate to make outbound calls to enterprise resources over the enterprise private network. Using a private network eliminates the need to route the traffic over the public internet, which could expose enterprise resources.

In a Virtual Network, you have full control over the outbound traffic from Power Platform. The traffic is subject to network policies applied by your network administrator. The following diagram shows how resources inside your network interact with a Virtual Network.

Screenshot that shows how resources inside an enterprise network interact with a Virtual Network.

Benefits of Virtual Network support

With Virtual Network support, your Power Platform and Dataverse components get all the benefits that Azure subnet delegation provides, such as:

  • Data protection: Virtual Network allows Power Platform services to connect to your private and protected resources without exposing them to the internet.

  • No unauthorized access: Virtual Network connects with your resources without needing Power Platform IP ranges or service tags in the connection.

Supported scenarios

Power Platform enables Virtual Network support for both Dataverse plug-ins and connectors. With this support, you can establish secured, private, outbound-connectivity from Power Platform to resources within your Virtual Network. Dataverse plug-ins and connectors enhance data integration security by connecting to external data sources from Power Apps, Power Automate, and Dynamics 365 apps. For example, you can:

  • Use Dataverse plug-ins to connect to your cloud data sources, such as Azure SQL, Azure Storage, blob storage, or Azure Key Vault. You can protect your data from data exfiltration and other incidents.
  • Use Dataverse plug-ins to securely connect to private, endpoint-protected resources in Azure, such as Web API or any resources within your private network, such as SQL and Web API. You can protect your data from data breaches and other external threats.
  • Use Virtual Network supported connectors like SQL Server to securely connect to your cloud-hosted data sources, such as Azure SQL or SQL Server, without exposing them to the internet. Similarly, you can use Azure Queue connector to establish secure connections to private, endpoint-enabled Azure Queues.
  • Use Azure Key Vault connector to securely connect to private, endpoint-protected Azure Key Vault.
  • Use HTTP With Microsoft Entra ID to securely connect to services authentication by Microsoft Entra ID.
  • Use custom connectors to securely connect to your services protected by private endpoints in Azure or services hosted within your private network.


  • Dataverse low-code plug-ins that use connectors aren't supported until those connector types are updated to use subnet delegation.
  • You can only use Copy and Restore environment lifecycle operations. If the source environment has Virtual Network enabled and the target doesn't, you can't do Copy and Restore.

Supported regions

Confirm that your Power Platform environment and enterprise policy are in supported Power Platform and Azure regions. For example, if your Power Platform environment is in the United States, then your Virtual Network, subnets, and enterprise policy must be in the eastus or westus Azure region.

Power Platform region Azure region
United States eastus, westus
South Africa eouthafricanorth, southafricawest
Uk uksouth, ukwest
Japan japaneast, japanwest
India centralindia, southindia
France francecentral, francesouth
Europe westeurope, northeurope
Germany germanynorth, germanywestcentral
Switzerland switzerlandnorth, switzerlandwest
Canada canadacentral, canadaeast
Brazil brazilsouth, southcentralus
Australia australiasoutheast, australiaeast
Asia eastasia, southeastasia
UAE uaecentral, uaenorth
Korea koreasouth, koreacentral
Norway norwaywest, norwayeast
Singapore southeastasia
Sweden swedencentral

Supported services

The following table lists the services that support Azure subnet delegation for Virtual Network support for Power Platform.

Area Power Platform services Virtual Network support
Dataverse Dataverse plug-ins Preview
Connectors Preview

Licensing requirements

Licensing requirements for Virtual Network support for Power Platform will be announced when the service is closer to general availability.

Considerations to enable Virtual Network support for Power Platform Environment

When you use Virtual Network support in a Power Platform environment, all supported services, like Dataverse plug-ins, connectors, execute requests at runtime in your delegated subnet and are subject to your network policies. The calls to publicly available resources would start to break.


Before you enable the virtual environment support for Power Platform environment, make sure you check the code of the plug-ins and the connectors. The URLs and connections need to be updated to work with private connectivity.

For example, a plug-in might try to connect to a publicly available service, but your network policy doesn't allow public internet access within your Virtual Network. The call from the plug-in is blocked in accordance with your network policy. To avoid the blocked call, you can host the publicly available service in your Virtual Network. Alternatively, if your service is hosted in Azure, you can use a private endpoint on the service before you turn on Virtual Network support in the Power Platform environment.


What's the difference between a virtual network data gateway and Azure Virtual Network support for Power Platform?

A virtual network data gateway is a managed gateway that allows you to access Azure and Power Platform services from within your virtual network without having to set up an on-premises data gateway. For example, the gateway is optimized for ETL (extract, transform, load) workloads in Power BI and Power Platform dataflows.

Azure Virtual Network support for Power Platform uses an Azure subnet delegation for your Power Platform environment. Subnets are used by workloads in the Power Platform environment. Power Platform API workloads use Virtual Network support because the requests are short-lived and optimized for a large number of requests.

What are the scenarios where I should use Virtual Network support for Power Platform and the virtual network data gateway?

Virtual Network support for Power Platform is the only supported option for all the scenarios for outbound connectivity from Power Platform except Power BI and Power Platform dataflows.

Power BI and Power Platform dataflows continue to use virtual network (vNet) data gateway.

How do you ensure that a virtual network subnet or data gateway from one customer isn't used by another customer in Power Platform?

  • Virtual Network support for Power Platform uses Azure subnet delegation.

  • Each Power Platform environment is linked to one virtual network subnet. Only calls from that environment are allowed to access that virtual network.

  • Delegation allows you to designate a specific subnet for any Azure platform as a service (PaaS) that needs to be injected into your virtual network.

Does Virtual Network support for Power Platform support failover?

Yes. While the feature is in public preview, you need to delegate a primary and failover virtual network and subnets during setup.

How can a Power Platform environment in one region connect to resources hosted in another region?

A Virtual Network linked to a Power Platform environment must reside in the Power Platform environment's region. If the Virtual Network is in a different region, create a Virtual Network in the Power Platform environment's region and use Virtual Network peering to bridge the two regions.

Can I monitor outbound traffic from delegated subnets?

Yes. You can use Network Security Group and firewalls to monitor outbound traffic from delegated subnets.

How many IP addresses does Power Platform need to be delegated in the subnet?

You need to delegate at least 24 Classless Inter-Domain Routing (CIDR), or 255 IP addresses, in the subnet. If you want to delegate the same subnet to multiple environments, you might need more IP addresses in that subnet.

Can I make internet-bound calls from plug-ins after my environment is subnet-delegated?

Yes. You can make internet-bound calls from plug-ins, but the subnet must be configured with an Azure NAT gateway.

Can I update the subnet IP address range after it's delegated to "Microsoft.PowerPlatform/enterprisePolicies"?

No. You can't change the IP address range of the subnet after it's delegated to "Microsoft.PowerPlatform/enterprisePolicies."

My Virtual Network has a custom DNS configured. Does Power Platform use my custom DNS?

Yes. Power Platform uses the custom DNS configured in the Virtual Network that holds the delegated subnet to resolve all endpoints. After the environment is delegated, you can update plug-ins to use the correct endpoint so that your custom DNS can resolve them.

My environment has ISV-provided plug-ins. Would these plug-ins run in the delegated subnet?

Yes. All customer plug-ins and ISV plug-ins can run, using your subnet. If the ISV plug-ins have outbound connectivity, those URLs might need to be listed in your firewall.

My on-premises endpoint TLS certificates aren't signed by well-known root certification authorities (CA). Do you support unknown certificates?

No. We must ensure the endpoint presents a TLS certificate with the complete chain. It's not possible to add your custom root CA to our list of well-known CAs.

We don't recommend any specific topology. However, our customers widely use the hub and spoke topology network model.

Is linking an Azure subscription to my Power Platform tenant necessary to activate Virtual Network?

Yes, to enable Virtual Network support for Power Platform environments, it's essential to have an Azure subscription associated with the Power Platform tenant.

How does Power Platform utilize Azure subnet delegation?

When a Power Platform environment has a delegated, Azure subnet assigned, it uses Azure Virtual Network injection to inject the container at runtime into a delegated subnet. In this process, a Network Interface Card (NIC) of container is allocated an IP address from the delegated subnet. The communication between the host (Power Platform) and the container occurs through a local port on the container, and the traffic flows over Azure Fabric.

Can I utilize an existing Virtual Network for Power Platform?

Yes, you can utilize an existing Virtual Network for Power Platform, as long as a single, new subnet within the Virtual Network is delegated specifically to Power Platform. It’s important to note that this delegated subnet shouldn't host any other services.

Can I use US East 2 as the failover if I have my Power Platform environment in Canada?

To ensure proper failover, the primary and failover subnets must be provisioned in canadacentral and canadaeast respectively. For effective failover, create the primary and failover subnets in the canadacentral and canadaeast regions, respectively. Additionally, establish Virtual Network peering between the primary and failover Virtual Networks, including the Virtual Network in the useast2 region for connectivity.

What is a Dataverse plug-in?

A Dataverse plug-in is a piece of custom code that can be deployed into a Power Platform environment. This plug-in can be configured to run during events (like a change in data) or triggered as a Custom API. Learn more: Dataverse Plug-ins

How does a Dataverse plug-in execute?

A Dataverse plug-in operates within a container. When a Power Platform environment is assigned a delegated subnet, an IP address from that subnet’s address space is allocated to the Network Interface Card (NIC) of the container. Communication between the host (Power Platform) and the container takes place through a local port on the container, with traffic flowing over Azure Fabric.

Can multiple plug-ins run within the same container?

Yes. In a given Power Platform or Dataverse environment, multiple plug-ins can indeed operate within the same container. Each container consumes one IP address from the subnet address space, and each container can execute multiple requests.

How does the infrastructure handle an increase in concurrent plug-in executions?

As the number of concurrent plug-in executions increases, the infrastructure automatically autoscales (out or in) to accommodate the load. The subnet delegated to a Power Platform environment should have sufficient address spaces to handle the peak volume of executions for the workloads in that Power Platform environment.

Who controls the Virtual Network and network policies associated with it?

As a customer, you have ownership and control over the Virtual Network and its associated network policies. Power Platform, on the other hand, utilizes the allocated IP addresses from the delegated subnet within that Virtual Network.

How can I configure Virtual Network support for Power Platform in Dev/Test environments without using two separate Virtual Networks in different Azure regions?

While having one Virtual Network and one dedicated subnet in each of your primary and secondary Azure regions is necessary for production workloads to ensure proper failover, for Dev/Test environments, we suggest utilizing a single Virtual Network with two dedicated subnets for Power Platform.

Next steps

Set up Virtual Network support