European Collaboration Summit

Power Platform governance – Environments

by Adis Jugo

governance | power platform
Power Platform Environments

Power Platform governance – Environments


Back in the days when Microsoft’s Power Platform first started, everyone could basically just jump on the bandwagon, and create their PowerApps and Flows. There was practically no governance possibilities, and barely any control whatsoever.

This was of course not enterprise ready in any possible way, so Microsoft has – some 18 months after the initial release – created the concept of “Environments”. In Microsoft’s own words, an environment is a space to store, manage, and share your organization’s business data, apps, and flows. It also serves as a container to separate apps that may have different roles, security requirements, or target audiences 

Basically, environments are isolation containers. One PowerApp, or one Flow, can belong only to one environment. Each connector must be defined per environment.

When you create data loss prevention policies, they need to be applied to an environment. I am often getting questions such as “Can I make my app available in two environments?”, or “Can I merge two environments?”. “No” is the answer on both of these questions: environments are physical isolation between your apps, flows, connectors and data – if you use and create Common Data Service database, they will also be contained to the environments. 

Users, on the other hand, can be members of multiple environments. Let’s take a short look at this schema: 

In the schema above we see a multinational company “Contoso”, which has created three different environments – Contoso USA, Contoso Canada and Contoso Australia. We also see three users, where users on the left and right side can only access their respective environments (and thus apps and flows), but the user in the middle has been assigned to all three environments, and can access PowerApps, Flows, connectors and data from all of them.  

Who can create environments? 

There is no group of whatever sorts which defines who can create environments, that you could populate and control the environment creation in that way. Rather, Microsoft states that it can be any Microsoft PowerApps Environment Admin, Office 365 Global Admin, or Azure Active Directory Tenant Adminwho needs to have a Plan2 license for PowerApps and/or Flow.

We will speak about PowerApps Environment Admins in future blog posts in this series, where we will discuss roles and permissions – but, for the beginning, you better get an Office 365 Global Admin or an AAD Admin to create environments.  

Even if a user is an Office 365 Global Admin (or AAD Admin), it does not necessary mean that that user has any permissions in an actual environment. As I mentioned before, that is something we will discuss later, but it often creates confusion: in the PowerApps or Flow portal, only those environments will be shown where the current user has rights.  

The picture above show the PowerApps portal where we can see that the current user, even if he’s an Office 365 Global Admin, sees only three environments in which he has permissions for.

If the user is a global admin, and can access the Microsoft PowerApps/Flow Admin center, all the environments will be shown there, and the admin can assign themselves necessary privileges on any chosen environment.  

In the screenshot above which shows the PowerApps admin center, we can notice that the same Office 365 Global Admin user can see all the environments, even those that they do not have permissions for.

Using PowerShell to Monitor, Create and Maintain Microsoft PowerApps and Flow Environments

Since there is no definitive closed list of who can create environments, Office 365 Admins will obviously be tasked with monitoring what is happening there and will have to perform protective and administrative actions. Now, obviously, that is possible from the PowerApps Admin Center, but that is a manual action which needs to be performed. 

Let’s see how we can save our precious time and automate it.  

Microsoft has recently published PowerShell modules for PowerApps and Flow makers and PowerApps admins. If you are administering PowerApps environments for your company, you will need both.  

First you will need the “PowerShell interface for Microsoft PowerApps and Flow” module which can be found here:  

Microsoft suggest that you install that module with clobbering allowed, since obviously it can conflict with commands from other modules – I could not figure out which ones, though.  

The second module you will need to install is “PowerShell interface for Microsoft PowerApps and Flow Administrative features”, which can be found here:

So, both commands will be:  

Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber 

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell

The next thing you will need to do is to connect to your PowerApps environment. Please use your Office 365 Global Admin account or AAD Admin account to do this: 


This will of course invoke a login prompt. You can use -Username and -Password switches to login directly without a login prompt.  

Once we are there, it is fairly simple to list existing environments. With this cmdlet, we’ll be performing this from the admin’s perspective: 

Get-AdminPowerAppEnvironment | Format-Table -Property EnvironmentName, DisplayName, CreatedBy, Location 

As result, we have listed all the environments in our tenant: 

In order to create a new environment, we will first get the list of available locations. That is done with the following cmdlet: 


As result, we will get the locations list: 

Now, let’s create a new trial environment in Europe. We will do it with the following cmdlet: 

New-AdminPowerAppEnvironment -DisplayName 'SysKit Dev' -Location europe -EnvironmentSku Trial 

The result of this cmdlet is the information about the newly created environment: 

In the same way, we can delete environments using PowerApps administrative commands. In order to do that, we will need to know the environment’s name – which is actually a GUID. Let us delete the environment we have created with the previous cmdlet: 

Remove-AdminPowerAppEnvironment -EnvironmentName b3242f6e-10d5-4590-9d4e-27c360896d61 

We should get code 202 as a result of this operation, which denotes that the delete operation was “accepted” successfully.