Introduction

When you team up Power Platform with Azure, you get a really powerful combo. For instance, you can keep your data in Azure SQL and pull it into Power Apps without a hitch. Or, use Power Automate to upload files directly to Azure Storage. It’s super smooth sailing, especially if your Azure resources are accessible publicly – you won’t need to mess with extra configurations.

But here’s where things get a bit trickier: when your Azure resources aren’t publicly accessible. If they’re locked down to specific virtual networks or even private endpoints, Power Platform tools generally can’t talk to them. That’s because, by default, Power Platform expects public access to make those connections.

But don’t worry, there’s good news! Microsoft has our backs with something called “Virtual Network for Power Platform“

Unfortunately, The official documentation is pretty poor, and there’s barely anything else helpful online (I personally spent two solid days trying to piece it together with no success!). Good news, though – I finally got it working! So, I decided to create this “zero-to-hero” blog post to make sure no one else has to go through the same time-consuming struggle.

---

Prerequisites

• You/your organizaion must have active Azure subscription
• In Azure, you must be at least network contributor role (I believe that some step may require more privileges, So, if you struggle with permission, try get help from your Admin or IT department)
• In Microsoft 365, you must be at least Power Platform Administrator role
• Your Power Platform environment must be ‘Managed Environment‘
• Download this GitHub repo as zip
• PowerShell
• Power Platform PowerShell module
• Azure PowerShell module

---

⚠️ Before We Dive In ⚠️

PLEASE READ THIS SECTION AS YOU WILL NOT BE WASTING YOUR TIME LIKE MINE.

I bet that most readers of this post will already have an existing Power Platform environment. First, you need to check the actual region of your environment because…

• If your environment is located in Singapore, it WILL NOT WORK;
• it’s IMPOSSIBLE to achieve successful VNET integration for Singapore environments.

I know, you might be thinking “but the Microsoft documentation says it should work!” However, after countless attempts, I can tell you: IT DOESN’T WORK.

To check region of your environment, you can just open command line and ping to environment’s endpoint.

Next, you need to check if your environment are in supported region listed below.

---

Let’s begin

1. Config resource provider for Azure subscription

Navigate to your Azure subscription > Resource providers.

Next, check if Microsoft.PowerPlatform is registered. If it’s not, go ahead and register it.

2. Create virtual networks

Now, you need to create two virtual network (one for primary and one for backup)that need to met these conditions:

• They must be in different Azure region
• They must be in same Power Platform region
• They must be in supported region for vnet integration (listed above)

Here’s some sample scenarios

• If your Power Platform environment are in ‘Asia’ (exclude Singapore)
  • Primary VNET should located in East Asia
  • Secondary VNET should locatedin Southeast Asia
• If your Power Platform environment are in ‘United States’
  • Primary VNET should located in West US
  • Secondary BNET should located in East US
  • (or in reverse)
• If your Power Platform environment are in ‘Japan’
  • Primary VNET should located in Japan East
  • Secondary VNET should located in Japan West
  • (or in reverse)

For me, my Power Platform environment is Asia, So I will create one in East Asia and one in Southeast Asia

I would recommend that these two virtual networks have different address spaces. This is just in case we need to do some peering later on.

After VNET was created, copy its resource id and paste in somewhere

To obtain VNET resource id, you need to click ‘JSON View’

3. Create subnet for each VNET

For VNET integration with Power Platform, it’s crucial to know you can’t use the default subnet. You’ll need a dedicated one.

So, your next step is to create a new subnet for Power Platform within each of your two VNETs.

During subnet creation, make sure that you’ve select “Microsoft.PowerPlatform/enterprisePolicies” under Subnet Delegation section.

4. Prepare information

We’ll need quite a few pieces of information for the next steps, so it’s a good idea to gather them all in one place, like a Notepad document.

• Azure subscription id
• Azure resource group name
• Power Platform environment id
• Power Platform region (must match with your environment), pick from:
  • unitedstates
  • unitedstatesfirstrelease
  • europe
  • asia
  • australia
  • india
  • japan
  • canada
  • unitedkingdom
  • southamerica
  • france
  • unitedarabemirates
  • germany
  • switzerland
  • norway
  • korea
  • southafrica
  • sweden
• Resource id of primary virtual network
• Resource id of secondary virtual network
• Subnet name (from both primary & secondary vnet)

5. Extract PowerApps-Samples-master

Remember GitHub repo that I tell you to download at Prerequisites its time to use it now.

Extract it somewhere and navigate to “PowerApps-Samples-master\powershell\enterprisePolicies\SubnetInjection“

6. Open PowerShell

Open PowerShell and navigate its to our folder from previous step using this command

cd "/path/to/your/folder"

7. Create enterprise policy

Now, we will create something called “Enterprise Policy” its like configuration to tell Power Platform to established connection to Azure virtual network

Use this command in PowerShell

.\CreateSubnetInjectionEnterprisePolicy.ps1

It will prompt you to enter information we prepared, just fill it.

It may prompt you to login to Azure, go ahead and login.

Once enterprise policy has created, it will returned you its resource id, write it down somewhere.

8. Inject policy to Power Platform

We’re so close to get this done. Now we need to inject the policy we just created to Power Platform environment so it can communicate with Azure virtual network

Using same PowerShell window, Run this command

.\NewSubnetInjection.ps1

It will prompt you to enter environment id and policy id (from previous step)

Once complete, the network injection status should show ‘Success’ in your Power Platform Admin Center’s environment history.

9. Allow virtual network to access your Azure resource

Don’t forget this! You needto config your Azure resource to allow connection from virtual network we just created

Go to your Azure resource. In my case, it was Azure SQL.

I go to the Networking settings and opt to allow only network from selected virtual networks to access this.

This is a huge security win because even if my SQL credentials somehow got exposed, no one could access my Azure SQL server – their network wouldn’t be permitted to connect.

Private access via Azure private endpoint is also supported.

10. Test it

It’s time to see if it work or not, you can test this with Power Automate, I create simple flow that just get rows from one of SQL table.

(As per SQL Server connector’s documentation, I need to put database name as variable/expression)

And just like that, I can now use data stored in Azure without exposing it to the public internet. Mission accomplished!

---

Conclusion

🎉 And there you have it!

Integrating Power Platform with your private Azure resources, especially when dealing with those tricky virtual networks and private endpoints, can seem daunting.

I certainly hit my head against a wall trying to navigate the sparse documentation and lack of online resources. But after a lot of persistence, I found the solution in Virtual Network for Power Platform.

Now, you can confidently connect to your private data and services without ever exposing them to the public internet, dramatically enhancing your security posture.

My hope is that this guide saves you the two days of frustration I went through, letting you focus on building amazing solutions with the Power Platform and Azure!