Power Platform Not Working, Delegation, Flow, and Data Source Fixes
Why Power Platform Stops Working, The Real Story
You built a Power Automate flow that worked perfectly in your dev environment. You pushed it to production. Nothing. Your canvas app can't reach the SQL backend. Your Power Pages portal throws a vague connectivity error. And the error message? Something completely unhelpful like "connection failed" or "resource unavailable", with no path forward.
I've seen this exact scenario on dozens of enterprise setups, and almost every time, the root cause traces back to one of three places: virtual network delegation misconfiguration, broken DNS resolution, or a region mismatch between your Power Platform environment and your Azure virtual network. Microsoft's error messages rarely tell you which one it is. That's why this guide exists.
Power Platform's enterprise connectivity model relies on a delegated subnet inside your Azure virtual network. When you delegate a subnet to Microsoft.PowerPlatform/enterprisePolicies, you're telling Azure that Power Platform can use that subnet to reach your private resources, your on-premises databases, your Azure SQL instances, your internal APIs. If anything in that chain is off, even by a single misconfigured DNS record, your flows, apps, and data connectors silently fail.
Here's what makes Power Platform virtual network issues particularly frustrating: one environment can work perfectly while another environment in what you think is the same region breaks. That happens because a single Power Platform region can actually span two Azure regions. Your environment can be sitting in either one, and it can fail over between them automatically. If you only configured your virtual network in one of those Azure regions, you've set yourself up for exactly this kind of intermittent failure.
Power Platform virtual network problems also show up differently depending on the workload. Power Automate flows that call private APIs start timing out. Power Apps using on-premises data gateways lose their connections. Dataverse connectors to external systems return authentication errors that are actually network errors in disguise. The symptom varies, but the diagnostic approach is the same.
The good news: Microsoft publishes a PowerShell diagnostics module, Microsoft.PowerPlatform.EnterprisePolicies, specifically to cut through the noise. It lets you run targeted tests against your environment and get real answers. This guide walks you through every step, from installing that module to fixing the most common Power Platform virtual network failures.
The Quick Fix, Try This First
Before you dig into DNS zones and private endpoints, run the official diagnostics module against your failing environment. This single step eliminates guesswork and tells you exactly where the break is. It takes about three minutes and catches the majority of Power Platform virtual network issues.
Open PowerShell as an administrator and run these two commands back to back:
Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies
Import-Module Microsoft.PowerPlatform.EnterprisePoliciesOnce the module is loaded, the first thing you want to check is whether your failing environment is in the region you think it's in:
Get-EnvironmentRegion -EnvironmentId "your-environment-id-here"Your environment ID is in the Power Platform admin center under Environments → [Your Environment] → Details. Copy it exactly, it looks like a GUID.
If the region comes back as something unexpected, that's your answer right there. You've configured your virtual network for the wrong region. If the region looks correct, follow up immediately with a DNS test against your target hostname:
Test-DnsResolution -EnvironmentId "your-environment-id-here" -HostName "your-resource-hostname.database.windows.net"If this test returns a public IP address for a resource that should be private, skip straight to Step 3 in the step-by-step section below. If this test returns an error saying the hostname can't be resolved at all, go to Step 2. If DNS resolves but you still can't connect, run:
Test-NetworkConnectivity -EnvironmentId "your-environment-id-here" -DestinationFqdn "your-resource-hostname" -DestinationPort 1433That tells you whether the network path itself is open. Most fixes flow from one of those three test results.
Everything in this guide starts here. The Microsoft.PowerPlatform.EnterprisePolicies module is the official Microsoft tool for diagnosing virtual network issues in Power Platform, and it's available from the PowerShell Gallery. Don't try to eyeball your network configuration manually, this module runs tests from within your delegated subnet context, which gives you results that actually reflect what Power Platform experiences.
Open PowerShell with administrator privileges. On Windows 11, press Start, type PowerShell, right-click Windows PowerShell or Terminal, and choose Run as administrator. Then run:
Install-Module -Name Microsoft.PowerPlatform.EnterprisePoliciesIf you're prompted about an untrusted repository, type Y and press Enter. This is the standard PowerShell Gallery prompt, it's expected. Once the installation finishes, import it into your active session:
Import-Module Microsoft.PowerPlatform.EnterprisePoliciesTo verify the module loaded correctly and see the full list of available functions, run:
Get-Command -Module Microsoft.PowerPlatform.EnterprisePoliciesYou should see functions including Get-EnvironmentRegion, Get-EnvironmentUsage, Test-DnsResolution, Test-NetworkConnectivity, and Test-TLSHandshake. If the module doesn't load or you see an error about execution policy, run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser first, then retry the import.
You should see the module prompt without errors. If you hit installation issues, the module's GitHub repository at PowerPlatform-EnterprisePolicies has the latest release and issue tracker. Don't try to troubleshoot a broken module by testing network connectivity manually, get the module working first, then run the diagnostics.
This is the step most admins skip, and it's the one that bites them later. When Power Platform says your environment is in "East US," that doesn't mean it's sitting in a single Azure region. Power Platform regions map to two underlying Azure regions to support high availability and automatic failover. Your virtual network configuration needs to cover both.
Run the region check against your failing environment:
Get-EnvironmentRegion -EnvironmentId "your-environment-id-here"And run the same command against any environment that is working:
Get-EnvironmentRegion -EnvironmentId "your-working-environment-id"Compare the outputs. If the regions differ, the virtual network subnet delegation that works for your healthy environment doesn't cover the region where your broken environment lives. This is one of the most common Power Platform virtual network issues I see in enterprise setups, admins configure delegation for one region and assume it covers everything.
Once you know both Azure regions for your Power Platform geography, you need to configure virtual network delegation and DNS in both of them. To run further diagnostics against a specific region rather than letting the module auto-detect, use the -Region parameter explicitly:
Test-DnsResolution -EnvironmentId "your-environment-id-here" -HostName "your-hostname" -Region "eastus2"Run this for both Azure regions. If one passes and one fails, you've confirmed a region-specific gap in your virtual network setup. The fix is to replicate your subnet delegation, DNS configuration, and private endpoint setup in the second Azure region. The Microsoft Power Platform regions documentation maps each Power Platform geography to its two supporting Azure regions, check that mapping before you configure anything.
When both regions return consistent results, move on to DNS testing.
DNS is the most common single point of failure for Power Platform virtual network connectivity. When your flow or app tries to reach myserver.database.windows.net, the DNS query goes out from your delegated subnet using whatever DNS server is configured for your virtual network. If that DNS server returns a public IP instead of the private endpoint IP, or can't resolve the hostname at all, the connection fails before it even starts.
Run the DNS test for your target resource:
Test-DnsResolution -EnvironmentId "your-environment-id-here" -HostName "myserver.database.windows.net"There are three possible outcomes:
Hostname not found: Your DNS server can't resolve the name at all. Check that your virtual network's DNS server settings are correct. If you're using a custom DNS forwarder, verify it can reach the upstream DNS servers and that your conditional forwarder rules are in place.
Resolves to a public IP: Your DNS is working but returning the wrong address. For Azure resources with private endpoints, this usually means a Private DNS Zone is missing or not linked to your virtual network. For example, Azure SQL Database needs a private DNS zone named privatelink.database.windows.net. If that zone doesn't exist, create it in the Azure portal under Private DNS Zones → + Create. Then link it to your virtual network under the zone's Virtual network links blade.
Resolves to a private IP: DNS is correct. Move on to network connectivity testing in Step 4.
For non-Azure resources, like an on-premises SQL server or a third-party API running in your datacenter, there's no private endpoint to create. Instead, add a DNS A record directly to your DNS server that maps the hostname to its private IP address. If you're using Azure-provided DNS, create an Azure Private DNS Zone and add the A record there, then link the zone to your virtual network.
After making any DNS changes, re-run Test-DnsResolution to confirm the hostname now resolves to the correct private IP. Don't skip the verification step, DNS changes can take a few minutes to propagate, and you want confirmation before declaring the fix done.
DNS resolving correctly is necessary but not sufficient. Your Power Platform environment also needs an open network path to the target resource on the right port. Firewall rules, network security groups, and private endpoint configurations can all block traffic even after DNS is working perfectly.
Use the Test-NetworkConnectivity function to check whether the connection can actually be established:
Test-NetworkConnectivity -EnvironmentId "your-environment-id-here" -DestinationFqdn "myserver.database.windows.net" -DestinationPort 1433Adjust the port to match your resource type. Common ports to test:
# Azure SQL Database
Test-NetworkConnectivity -EnvironmentId "env-id" -DestinationFqdn "server.database.windows.net" -DestinationPort 1433
# Azure Storage (blob)
Test-NetworkConnectivity -EnvironmentId "env-id" -DestinationFqdn "account.blob.core.windows.net" -DestinationPort 443
# Custom internal API
Test-NetworkConnectivity -EnvironmentId "env-id" -DestinationFqdn "internal-api.company.local" -DestinationPort 8443If the test fails with a timeout or connection refused error, the network path is blocked. Check these in order:
- The Network Security Group (NSG) on your delegated subnet, make sure outbound rules allow traffic to the destination IP and port.
- The NSG on the destination resource's subnet, inbound rules must allow traffic from your delegated subnet's address range.
- The private endpoint's network interface, verify it's in the same virtual network or a peered network that your delegated subnet can reach.
- Any Azure Firewall or third-party NVA sitting between your delegated subnet and the destination, check its rule collection for deny entries matching your traffic.
When the test passes, you'll see a successful connection result. Run it against both Azure regions for your Power Platform geography before moving on, connectivity can be asymmetric if your routing setup isn't mirrored correctly across regions.
Network connectivity open but Power Platform still failing? The last layer to check is TLS. Power Platform requires a successful TLS handshake with the target resource. If the certificate presented by the resource is self-signed, issued by an internal CA that Power Platform doesn't trust, or expired, the connection gets dropped at the TLS layer, and the error message you see in Power Automate or Power Apps rarely mentions certificates.
Run the TLS handshake test:
Test-TLSHandshake -EnvironmentId "your-environment-id-here" -HostName "myserver.database.windows.net" -Port 443If this test fails while Test-NetworkConnectivity passes, you have a TLS trust issue. For Azure-managed resources like Azure SQL Database or Azure Storage, this shouldn't happen, Microsoft's certificates are already trusted. Where this comes up most often is with on-premises resources or internal APIs running self-signed or corporate CA certificates.
For on-premises resources exposed through a private endpoint or VPN, make sure the resource is presenting a certificate issued by a publicly trusted CA, or that your virtual network's DNS and routing are configured so Power Platform reaches the resource through an Azure service (like Azure API Management) that fronts the internal system with a valid certificate.
Also check the certificate's expiration date. I've seen Power Platform connectivity mysteriously break on exactly the day a certificate expired, not because anyone changed anything, but because an IT team set-and-forgot a cert years earlier. If Test-TLSHandshake returns a certificate expiry error, renew the certificate on the target resource.
After fixing the TLS issue, re-run all three tests in sequence: Test-DnsResolution, Test-NetworkConnectivity, and Test-TLSHandshake. All three passing means your Power Platform virtual network connectivity chain is healthy. Go back to your flow or app and test again, it should work now.
Advanced Troubleshooting for Power Platform Virtual Network Issues
If the five steps above didn't resolve your Power Platform virtual network problem, you're dealing with something more specific to your environment's configuration. Here's how to go deeper.
Environment Usage and Quota Problems
Sometimes Power Platform stops working not because of a network misconfiguration but because an environment has hit a usage threshold that's affecting its ability to process requests through the virtual network. Use the Get-EnvironmentUsage function to pull current usage data:
Get-EnvironmentUsage -EnvironmentId "your-environment-id-here"If you see high utilization figures, the environment may be throttling requests before they even hit the network layer. This shows up in Power Automate as intermittent flow failures that seem network-related but are actually capacity-related.
Virtual Network Delegation Verification
Your subnet must be explicitly delegated to Microsoft.PowerPlatform/enterprisePolicies. In the Azure portal, go to Virtual Networks → [Your VNet] → Subnets → [Your Delegated Subnet]. Under Subnet delegation, confirm the value shows Microsoft.PowerPlatform/enterprisePolicies. If it shows nothing or a different service, the delegation is missing or incorrect, Power Platform will not be able to use that subnet.
Also check the subnet size. Microsoft recommends a minimum of /24 for the delegated subnet. A subnet that's too small can cause Power Platform to fail provisioning new connections, which shows up as intermittent Power Platform connectivity errors rather than a clean "subnet full" message.
When One Environment Works but Another Doesn't
This is the Power Platform scenario that causes the most confusion. You have two environments, dev works, prod doesn't. Both should be in the same region. Run Get-EnvironmentRegion against both and compare the output character by character. If they return different Azure region identifiers, your subnet delegation and DNS configuration aren't covering the region where the failing environment actually lives.
The fix is to replicate your virtual network configuration in the second Azure region: create a new virtual network (or extend peering), delegate a subnet to Microsoft.PowerPlatform/enterprisePolicies, recreate your private endpoints, and link your private DNS zones to the new virtual network. Then re-run diagnostics with the -Region parameter pointing at the second region to confirm everything is working there too.
Reporting Module Issues
If the diagnostics module itself throws errors, not the resources you're testing, but the module functions themselves, report them through the PowerPlatform-EnterprisePolicies GitHub repository. Go to the Issues tab and open a new issue with the exact error message, any relevant log output, and your PowerShell version ($PSVersionTable). Strip out any environment IDs, hostnames, or IP addresses before posting, don't include sensitive infrastructure information in a public issue.
If you've run all diagnostics, all tests pass, and Power Platform still fails, especially if the problem is environment-specific and you can't reproduce it in dev, it's time to escalate. Open a support ticket at Microsoft Support with your environment IDs, the diagnostic module output (sanitized), and a clear description of what's failing and when it started. Power Platform support engineers have access to backend telemetry that the diagnostics module can't surface, and they can see whether the issue is on Microsoft's infrastructure side rather than your configuration. Don't spend more than 4 hours debugging after all visible configuration looks correct, escalate instead.
Prevention & Best Practices for Power Platform Virtual Network Stability
Power Platform virtual network issues are almost always preventable. The most painful incidents I've seen, ones that took environments down for hours, came from skipping steps that take 20 minutes to do right the first time. Here's what that looks like in practice.
Configure both Azure regions from day one. Every time you set up a Power Platform environment with virtual network support, identify both Azure regions for your Power Platform geography before you start. Configure your subnet delegation, private endpoints, and DNS zones in both regions simultaneously. Don't plan to "add the second region later", later becomes never, and the first failover event will take you by surprise.
Run diagnostic tests after every network change. Any time you modify DNS settings, NSG rules, private endpoints, or virtual network peering, run the full diagnostics module suite before calling the change done. Run Test-DnsResolution, Test-NetworkConnectivity, and Test-TLSHandshake against every Power Platform environment that depends on the changed infrastructure. This takes five minutes and prevents hours of incident response later.
Use Private DNS Zones for every Azure resource with a private endpoint. Don't rely on custom host file entries or manual DNS A records for Azure-managed resources. Private DNS Zones integrate automatically with private endpoints and update themselves when endpoint IPs change. For Azure SQL Database, that zone is privatelink.database.windows.net. For Azure Storage blobs, it's privatelink.blob.core.windows.net. Create one per resource type and link it to every virtual network that houses a Power Platform delegated subnet.
Size your delegated subnet appropriately. Plan for growth. A /24 subnet gives you 256 addresses, which is usually enough for small to medium deployments. If you're running multiple Power Platform environments in enterprise scale, consider /22 or larger. Resizing a delegated subnet later requires removing the delegation, resizing, and re-delegating, a change window you don't want to schedule under pressure.
Document your Power Platform region-to-Azure region mapping. Keep a living document that maps each Power Platform environment to its Power Platform geography, its two Azure regions, the virtual network and subnet names, and the private DNS zones linked to those networks. When something breaks at 11 PM, you want that information in front of you immediately, not buried in the Azure portal.
- Pin the Power Platform admin center and Azure Virtual Networks blade to your browser bookmarks, you'll visit both constantly when troubleshooting
- Create an Azure Monitor alert on your delegated subnet's NSG flow logs to catch unexpected traffic denials before they turn into Power Platform failures
- Set a calendar reminder 60 days before every TLS certificate expiry on resources that Power Platform connects to, Power Platform has no native cert expiry alert
- Keep the
Microsoft.PowerPlatform.EnterprisePoliciesmodule updated:Update-Module -Name Microsoft.PowerPlatform.EnterprisePolicies, new diagnostic functions get added as Microsoft identifies new failure patterns
Frequently Asked Questions
Can I update the DNS server address on my virtual network after it's already delegated to Microsoft.PowerPlatform/enterprisePolicies?
Yes, you can update the DNS server settings on a virtual network that's already delegated, you don't need to remove the delegation first. In the Azure portal, go to Virtual Networks → [Your VNet] → DNS servers and update the address there. The change takes effect for new DNS queries from the delegated subnet. After updating, run Test-DnsResolution -EnvironmentId "your-env-id" -HostName "your-target-hostname" from the diagnostics module to confirm the new DNS server is resolving hostnames correctly from Power Platform's perspective. Note that existing active sessions may not immediately pick up the new DNS, a brief wait or environment restart may be needed for full propagation.
Why does my Power Platform flow work in dev but fail in production when both environments seem to be in the same region?
This is the most common Power Platform virtual network mystery, and the answer almost always comes down to one of two things: the two environments are actually in different Azure regions underneath the same Power Platform geography label, or the production environment has failed over to the secondary Azure region and your virtual network isn't configured there. Run Get-EnvironmentRegion against both environment IDs and compare the output directly. If they return different Azure region identifiers, replicate your subnet delegation, private endpoints, and private DNS zone links in the production environment's actual Azure region. Power Platform regions span two Azure regions, and you need both covered.
My Test-DnsResolution returns a public IP instead of a private IP for my Azure SQL Database, how do I fix it?
This means your virtual network is missing either a private DNS zone or the link between that zone and your network. In the Azure portal, search for Private DNS Zones and look for a zone named privatelink.database.windows.net. If it doesn't exist, create it. Then go into that zone's Virtual network links blade and add a link to the virtual network containing your Power Platform delegated subnet. Once linked, the DNS zone automatically returns the private endpoint's IP address for your SQL server hostname. Re-run Test-DnsResolution after a few minutes to confirm the hostname now resolves to the private IP.
Power Platform can't connect to an on-premises resource that doesn't have an Azure private endpoint, what do I do?
For non-Azure resources that don't have a private endpoint, like an on-premises database server or a custom API running in your own datacenter, you need to configure your DNS server to manually map the resource's hostname to its private IP address. If you're running a custom DNS server on-premises or in Azure, add a DNS A record there directly. If you're relying on Azure-provided DNS, create an Azure Private DNS Zone, add the A record pointing the hostname to the private IP, and link the zone to your Power Platform virtual network. After that, run Test-DnsResolution from the diagnostics module to verify the mapping is working, then follow up with Test-NetworkConnectivity to confirm the network path is open.
How do I find my Power Platform environment ID to use with the diagnostics module?
Go to the Power Platform admin center at admin.powerplatform.microsoft.com. In the left navigation, click Environments and select the environment you want to diagnose. On the environment details page, look for the Environment ID field, it's a GUID that looks like xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Copy it exactly, including all hyphens, and paste it as the value for the -EnvironmentId parameter in any diagnostics module command. You can also get the environment ID from the environment's URL in the admin center, it appears as part of the path after /environments/.
Where do I report bugs or issues in the Microsoft.PowerPlatform.EnterprisePolicies diagnostics module itself?
Report module issues through the official GitHub repository for the project, search for PowerPlatform-EnterprisePolicies on GitHub. Go to the Issues tab and open a new issue. Include your PowerShell version (run $PSVersionTable and paste the output), the exact command you ran, and the full error message or unexpected output you received. Before posting, remove any sensitive information, environment IDs, hostnames, IP addresses, and tenant identifiers should not appear in public issue reports. The module team monitors the repository actively and this is the fastest path to getting a module-level fix.