Managing Microsoft PowerApps and Flow Like a Pro – Part 2

In this blog post, we will discuss the management of content inside the environments. We will focus on Microsoft PowerApps in this post (Flow will follow later), and we will see how to get an insight into what’s going on within the environments.  

In my previous post Managing Microsoft PowerApps and Flow Like a Pro – Part 1”, I discussed the concept of “environments” within Microsoft PowerApps and Flow. We have seen what environments are, and how you can automate their monitoring and management in the context of Microsoft PowerApps – a task that administrators are being asked to do more and more on a regular basis 

Let’s just refresh some basic knowledge here: all PowerApps and Flows live within environments, which are their boundary and execution space. All the data that PowerApps and Flow access must be defined through connectors which are stored in that same environment. There are hundreds of connectors available for PowerApps and Flows, but you can also develop your own connectors (which are then called “custom connectors”)Your custom connectors have to also live within the same environment. Last but not least – the users.

We have seen in the last blog post that within an environment we can differentiate between administrators (who can do everything with an environment), makers (people who can create and edit apps), and normal users (who don’t have to be defined on the environment level – we will grant their PowerApps usage within an app).

What is Microsoft PowerApps, Microsoft Flow, Users and Connectors

Now, let’s take a sneak peek inside the environments by using PowerShell and see how we can automate some of those PowerApps-related tasks. First things first: in the previous blog post we discussed which PowerApps Modules you will need for this, so go on and install them if you already haven’t.

Working with Microsoft PowerApps inside an environment 

The first thing we will want to know as an admin is what apps do we have in our environment? We will use the “Get-AdminPowerApp” PowerShell Cmdlet for this:

Get-AdminPowerApp | Where-Object {$_.EnvironmentName -eq $YourEnvironmentId } | Format-Table -Property DisplayName, CreatedTimeEnvironmentName 

Microsoft PowerApps in our Environment

In the screenshot above, we see all the PowerApps we have in our environment (please set the $YourEnvironment variable to your Environment’s ID – we’ve shown in the previous blog post how to get it).  

Furthermore, we will probably want to know who the App owner is. For that purpose, we need to expand the Owner property (which is an object itself) and to fetch its display name or whatever other property we might want to have: 

Get-AdminPowerApp | Where-Object {$_.EnvironmentName -eq $YourEnvironmentId | Select AppNameCreatedTime -ExpandProperty Owner | Format-Table -Property AppNameCreatedTime, DisplayName 

Who the Microsoft PowerApps owner is

In the screenshot above, we see the owners of the all the apps in this environment.  

Connections contained in our environment

One of the most important things in an environment are the connections which it contains. Connections are the gateways to our underlying data – it is the place where we define which data sources PowerApps and Flows can use inside one environment. In one of the following blog posts, we will discuss how to control those connections with data policies, but let’s see here how to get insight into existing connections in our environments.  

To get all the connections in our environment, we will use the following PowerShell Cmdlet: 

Get-AdminPowerAppConnection | Where-Object {$_.EnvironmentName -eq $YourEnvironmentName } 

 The result will look like something like this: 

Connections in our Environment

For each and every connection in this environment, we see the connector it uses, its name, who has created it and when, and its status (connected, inactive, etc). You can of course easily drill down into those results, or filter thembased on your requirements.

But, knowing your connections without having a context in which they are used, is only partially useful. We need to know which PowerApps are using which connections.  

In order to achieve that, we will have to iterate through the apps in the environment, and to call the “Get-AdminPowerAppConnectionReference” Cmdlet for each app that has been found: 

$allApps=Get-AdminPowerApp | Where-Object{$_.EnvironmentName-eq$envname} | SELECT AppName,CreatedTime,EnvironmentName
foreach($app in $allApps) {
 $app.AppName
 Write-Output"=========="
 Get-AdminPowerAppConnectionReferences-EnvironmentName $envname-AppName $app.AppName | SELECT ConnectorName,ConnectorId,DisplayName,Publisher
}

The result of this little script iterates all the apps and gives us the connector status per app: which connector has been used, and who is the publisher of that connector. 

Microsoft PowerApps and Connector Status

Now, that’s already better. But if you have hundreds of apps and hundreds of connectors, this view might be cluttered. For example, we might want to only search for the apps that use a specific connector, and while this view would give you back that information, it would not be easy to find 

We can achieve that goal with this little script. Here we are looking for all of the PowerApps that are using the Twitter connector. For example, it might happen that we notice unauthorized tweets with sensitive data being tweeted through one of our PowerApps, and this will show us where it might be: 

$envname="Default-b52fadc5-e236-4e84-a7ec-99950c1a9647";
$connectorname = "shared_twitter";

$allApps = Get-AdminPowerApp | Where-Object {$_.EnvironmentName -eq $envname} | SELECT AppName, CreatedTime, EnvironmentName

foreach ($app in $allApps) {
 
 $Connectors = Get-AdminPowerAppConnectionReferences -EnvironmentName
$envname -AppName $app.AppName | Where-Object {$_.ConnectorName -eq $connectorname} | SELECT ConnectorName, ConnectorId, DisplayName, Publisher
 $ConnectorCount = ($Connectors).Count

 if ($ConnectorCount -ne 0) {
 Write-Output $app.AppName
 }
}

The result of this script will be the IDs of all the PowerApps in this environment that use the twitter connector. Now its easy to go and look at those apps and find out what they are really doing. 

ID of all the Microsoft PowerApps in the Environment

One last thing I didn’t mention here are the custom connectors. They are not part of the Cmdlets stated above – they have their own Cmdlets.  

The most important Cmdlet we want to use here is “Get-AdminPowerAppConnector”: 

Get-AdminPowerAppConnector | SELECT DisplayName, CreatedTimeCreatedBy 

This Cmdlet lists all the custom connectors we have: 

List of all the Custom Connectors

In the screenshot above, we see all the custom connectors, together with the creation time and who created them. If we would drill down further into the results, we could also get detailed information about the status of each of these connectors, including the Swagger definitions.

Now, we can use the results from this script, in combination with the Get-AdminPowerAppConnectionReferences Cmdlet to figure out which apps are using which of those custom connectors, just as we have done above for the twitter connector – the procedure would be the same.

User’s perspective on managing Microsoft PowerApps

I will finish this blog post with a few ideas on how to manage PowerApps from the users’ perspective. As we have said before, we can differentiate users between administrators (who can do everything within an environment), makers (who can create and edit apps), and normal users (who don’t have to be defined on the environment level – we grant their PowerApps usage within an app).

To get all Administrator and Maker roles for an environment, we will use the following Cmdlet: 

Get-AdminPowerAppEnvironmentRoleAssignment | Where-Object {$_.EnvironmentName -eq $YourEnvironmentName} | SELECT RoleIdRoleNameRoleType,  PrincipalDisplayNamePrincipalTypePrincipalObjectId 

Administrator and Maker Roles for an environment

From the results above, we can see that we have one Administrator and two Makers within this environment.  

The other useful command here is how many PowerApps each of your users own per environment: 

Get-AdminPowerApp | Select –ExpandProperty Owner | Select –ExpandProperty displayname | Group 

Number of Microsoft Powers Apps each of your users own

In the screenshot above, we see the app ownership on a per-user basis, so we can know which users are creating a lot of PowerApps

What we will often need as administrators is to list PowerApps with one or more users, together with the roles that user has on that app – is the user the app Owner, or if the user can only edit or view that PowerApp. 

This little script will iterate our users in the environment, and check their app permissions:

$principals = Get-AdminPowerAppEnvironmentRoleAssignment | Where-Object
{$_.EnvironmentName -eq $envname} | SELECT RoleId, RoleName, RoleType, PrincipalDisplayName, PrincipalType, PrincipalObjectId

For each ($principal in $principals)
{
 $principal.PrincipalDisplayName
 Write-Output "-------------------------"
 Get-AdminPowerAppRoleAssignment -UserId $principal.PrincipalObjectId | Where-Object {$_.EnvironmentName -eq $envname } | Select RoleID, PrincipalType, RoleType, AppName
}

The result is a list of apps for each of our environment users: 

List of apps for each of our environment users

Conclusion on  Microsoft PowerApps and Microsoft Flow

In this blog post, we have seen how to view and manage content inside our environments: PowerApps, Connections, user roles, user permissions within the environments and single apps. In the next blog post, we will focus on similar tasks with Microsoft Flow.