Transition to List Flows as Admin V2 from deprecated List Flows as Admin action on the Power Automate Management connector

[ChrisGarty]

Hi community! 

What's changing?

The List flows as Admin action on the Power Automate Management connector has been deprecated in favor of the List Flows as Admin (V2) action. The List Flows as Admin (V2) action can list all flows in an environment. The V2 action and its backing API has higher performance, since it returns only the identifying information about the flow. To accomplish this performance increase, the flow definition and some other metadata isn't returned. If the flow definition or additional metadata is needed, then a subsequent call can be made to the Get Flow as Admin action.

The Get-AdminFlow PowerShell cmdlet is also being updated to call the V2 List Flows API instead of the V1 List Flows API. This change will remove support for the CreatedBy filter.

The Center of Excellence (CoE) Starter Kit was updated to call the V2 List Flows API instead of the V1 List Flows API and that change was in the May 2023 release.

Why is this change happening?

The V2 API has higher performance, since it returns only the identifying information about the flow. The transition away from the V1 API is being made to minimize future disruptions to customer services.

How do I adjust to the change?

If you don't use the Center of Excellence (CoE) Starter Kit, the List flows as Admin action on the Power Automate Management connector, or the Get-AdminFlow PowerShell cmdlet, then you won't need to make any changes.

Connector actions: To take advantage of the increased performance of the V2 action and move off the V1 action, simply transition to using the List Flows as Admin (V2) action instead.

PowerShell: The Get-AdminFlow PowerShell cmdlet has been updated in version 2.0.165. You can update your copy of the Power Platform PowerShell cmdlets using Update-Module -Name "Microsoft.PowerApps.Administration.PowerShell". You can check your version using Get-Module -Name "Microsoft.PowerApps.Administration.PowerShell".

CoE Starter Kit: Update to the latest release of the CoE Starter Kit.

How do I find connector actions?

If you aren’t sure which flows might be calling the List flows as Admin action, then you can create a flow to list those flows. The List flows as Admin action has an operation ID of “ListFlowsInEnvironment”, so call the List Flows as Admin (V2) action, iterate over those flows calling the Get Flows as Admin action for each, parse JSON on the “actions” result, and then look for a “swaggerOperationId” of “ListFlowsInEnvironment”.

What's the timeline?

Connector design-time: Enforcement of the connector action deprecation at design-time is currently happening, so new flows will need to use the List Flows as Admin (V2) action. The design-time change finished rolling out to production environments 6/15.

Runtime: In August, we'll evaluate migration progress and start enforcing the deprecation at runtime, so that calls to the backing API may begin to fail at runtime. In time this will affect the old PowerShell cmdlet versions, old CoE Starter Kit versions, and calls to the deprecated List flows as Admin action.

What if I miss something?

We'll be watching usage levels of the deprecated List flows as Admin action, and its backing API, and we will reach out to customers that continue to have significant usage by the end of July.

Where can I read more?

You can read the latest guidance in the Administer environments and Power Automate resources documentation.

Who can I contact for more information?

Please ask any questions that you may have here and we'll get you answers. Thanks!

*** Update October 19, 2023 *** 

Thanks to community feedback, List Flows as Admin V2 + Get Flow as Admin APIs should now be functionally equivalent to List Flows as Admin V1 API.

List Flows as Admin V2 API is now:

- Working correctly in GCC

- Returning createdBy, createdTime, and lastModifiedTime

Get Flow as Admin API is now:

- Returning flow definition

Module Microsoft.PowerApps.Administration.PowerShell updated

We are going to start failing a small number of calls to the V1 List Flows as Admin API to encourage migration to the V2 API, the V2 action, and the latest PowerShell cmdlets module. For now, the failures will randomly occur on less than 1% of calls to the V1 API. 

This is the error that would be returned to calls to the API directly or via the connector:
The List Flows as Admin API is no longer supported. Please use the List Flows as Admin (V2) action
And this is the error message that will be returned from the PowerShell cmdlet:
The List Flows as Admin API used by this PowerShell cmdlet version is no longer supported. Please update to the latest PowerShell cmdlet using Update-Module

This change will roll out as RP/2310.3: Preview ~Oct 17, Canada ~Oct 24, Early regions ~Oct 25, Asia ~Oct 27, Europe ~Oct 31, North America ~Nov 2, GCC ~Nov 6.

If you encounter these error messages then please take the remediation actions described.

[ChrisGarty]

Additionally, here is a PowerApps admin module PowerShell script that an admin can run to get a list of flows that are using the deprecated action:

#Find flows using a specific action within all cloud flows in the tenant
$startTime = Get-Date
#The name for the Power Automate Management connector is shared_flowmanagement
$targetConnectorName = "shared_flowmanagement"
#The name for the List Flows as Admin action is ListFlowsInEnvironment
$targetActionName = "ListFlowsInEnvironment"

$myStrings = @()
$totalFlowCount = 0
$targetFlowActionCount = 0
$totalFlowActionCount = 0
$environments = Get-AdminPowerAppEnvironment
foreach ($environment in $environments) {
    $environmentName = $environment.EnvironmentName
    $environmentDisplayName = $environment.DisplayName
    $flows = Get-AdminFlow -EnvironmentName $environmentName
    $totalFlowCount = $totalFlowCount + $flows.Count
    foreach ($flow in $flows) {
        $flowName = $flow.FlowName
        #Call Get-AdminFlow again with the FlowName parameter so it retrieves the definitionSummary
        $detailedFlow = Get-AdminFlow -EnvironmentName $environmentName -FlowName $flowName
        foreach ($action in $detailedFlow.Internal.properties.definitionSummary.actions) {
            # Make sure it is a valid action
            if ($action.swaggerOperationId) {
                $totalFlowActionCount++
                # Check if action name and connector name are a match
                if (($action.swaggerOperationId -eq $targetActionName) -and ($action.api.name -eq $targetConnectorName)) {
                    $targetFlowActionCount++
                    $flowDisplayName = $flow.DisplayName
                    $connectorName = $action.api.name 
                    $actionName = $action.swaggerOperationId
$jsonOutput = @"
{
  "environmentName": "$environmentName",
  "environmentDisplayName": "$environmentDisplayName",
  "flowName": "$flowName",
  "flowDisplayName": "$flowDisplayName",
  "connectorName": "$connectorName",
  "actionName": "$actionName"
}
"@
                    $myStrings += $jsonOutput
                } 
            } 
        } 
    }
}
# Output the captured strings
foreach ($string in $myStrings) {
    Write-Host $string
}
Write-Host "Target connector was $targetConnectorName and target action was $targetActionName"
Write-Host "Target flows actions count: $targetFlowActionCount"
Write-Host "Total flows actions count: $totalFlowActionCount"
Write-Host "Total cloud flows count: $totalFlowCount"
$endTime = Get-Date
$duration = $endTime - $startTime
Write-Host "Script execution time: $duration"

[max81]

Did I miss the Message Center News about this?
So I have now to update several flows in just a few weeks?

I'm not happy...

By the way: there are still active templates that using this action. 🙄

[ChrisGarty]

@max81, Hopefully the flows are easy to transition! Message center communication was a little delayed, but just went out. We’ll watch the migration progress to try to ensure the impact is minimal. We will get the templates switched over, but let us know if you see any needing attention. 
Thanks!

[max81]

@ChrisGarty : thanks for your feedback.
It depends on your definition for "easy". But it will take some time to migrate these flows. Summer time and holiday season and the short time period doesn't really help 😉

Is there a possibility to get some additional weeks for migration?

[mzandegiacomo]

Hello @ChrisGarty 
Thanks for your message. I definitely think that the transition period is too short and we need more time. Especially in large environments, upgrading the CoE Toolkit is not done so quickly as it needs some testing and environment-specific adjustments before a new version can be used. Especially since the transition period falls in summertime and was announced at far too short notice.
I think the start of enforcing the deprecation at runtime should be postponed until the end of september.
Thanks, Martin

[max81]

Message Center Info has been released a few days ago - just adding it so other users can find this post more easily

MC624197

[Nazul]

This is very disappointing.

First, this was started back in June, and MC624197 was published July 4, so we find out about this weeks later when it was published in MC. And it is going to be enforced in August. Poor communication in my perspective.

And about the change, it is reducing the data is sending back to improve your process, but making ours more complicated and slower. We have over 4K+ flows, so it was enough for most of the scenarios to do a simple Get-AdminFlow -EnvironmentName $defaultEnvName, but now we are forcing to get all flows, and then run the slower version per each flow. Like this.

$flows = Get-AdminFlow -EnvironmentName $defaultEnvName

$tmpFlows = @()
foreach ($tmpFlow in $flows) {
$tmpFlows += Get-AdminFlow -EnvironmentName $tmpFlow.EnvironmentName -FlowName $tmpFlow.FlowName
}
$flows = $tmpFlows

It might be improved if we try to run some paralelism here, but if so, we might reach some thresholds because too many API calls at the same time.

We have an increased time from just a few seconds for the Get-AdminFlow to 3 hours to get all details just because of the missing CreatedBy data.

[ChrisGarty]

@Nazul, the CreatedBy data is something we are trying to add into the V2 result. Is that the only piece of data that is causing you to call “Get-AdminFlow -FlowName” for each flow?

[ChrisGarty]

@max81 and @mzandegiacomo , thanks for the feedback on the timeline. We’ll watch usage of the older API and evaluate where we are in August. Thanks for starting your transitions now to provide us with feedback!

[IAmIntractable]

This new action is not working properly. The displayName should not contain a GUID but the actual current name of the flow. Also, I do not believe it is returning flows that are considered soft-removed. 

[Nazul]

As part of this change, yes, the CreatedBy is the primary attribute that is causing issues for us. It's not the only one that is missing (description is missing too).

In some processes, we had to go and get individual details for all flows anyway in the past (like used connectors). It shouldn't be this way.

[ChrisGarty]

@IAmIntractable , the DisplayName value should be a string. The FlowName value should be a GUID. Could you double check that? Results in PowerShell should look like this:

PS C:\Users\cgarty> Get-AdminFlow


FlowName : 01a2b422-2214-c07d-fe91-a5d76f154705
Enabled : True
DisplayName : ModelDriven Flow
UserType :
CreatedTime : 2021-01-25T07:47:21Z
CreatedBy :
LastModifiedTime : 2021-01-26T16:22:37Z
EnvironmentName : 03ff31c6-90c5-451b-810b-34992b4be0dc
WorkflowEntityId : 6c631d89-e15e-eb11-a812-000d3a322191
Internal : @{name=01a2b422-2214-c07d-fe91-a5d76f154705; id=/providers/Microsoft.ProcessSimple/environments/03ff
31c6-90c5-451b-810b-34992b4be0dc/flows/01a2b422-2214-c07d-fe91-a5d76f154705;
type=Microsoft.ProcessSimple/environments/flows; properties=}

FlowName : 072e1365-e295-1e1c-00a6-a889c44756d1
Enabled : True
DisplayName : Alert Warehouse & Technician
UserType :
CreatedTime : 2021-01-28T19:07:15Z
CreatedBy :
LastModifiedTime : 2021-03-04T17:08:57Z
EnvironmentName : 03ff31c6-90c5-451b-810b-34992b4be0dc
WorkflowEntityId : eff8c205-9c61-eb11-a812-000d3a322690
Internal : @{name=072e1365-e295-1e1c-00a6-a889c44756d1; id=/providers/Microsoft.ProcessSimple/environments/03ff
31c6-90c5-451b-810b-34992b4be0dc/flows/072e1365-e295-1e1c-00a6-a889c44756d1;
type=Microsoft.ProcessSimple/environments/flows; properties=}

 Could you explain more what you mean by "soft-removed"? Do you mean Enabled=False?

[Nazul]

We are now reaching another issue because of this change.

Because we need to run a Get-AdminFlow per each flow in the environment and store the results in memory, we have more memory comsuption and the server goes out of memory.

An example of the difference in a small test environment.

PS C:\> Get-AdminFlow -EnvironmentName $testEnv | ConvertTo-Json -Compress | Out-File C:\Temp\all.json
PS C:\> Get-AdminFlow -EnvironmentName $testEnv | % {Get-AdminFlow -EnvironmentName $_.EnvironmentName -FlowName $_.FlowName} | ConvertTo-Json -Compress | Out-File C:\Temp\detailed.json
PS C:\> dir C:\Temp\*.json


    Directory: C:\Temp


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        7/12/2023   8:14 AM         816726 all.json
-a----        7/12/2023   8:33 AM        1142458 detailed.json


PS C:\> Get-AdminFlow -EnvironmentName $testEnv | Measure-Object


Count    : 448
Average  :
Sum      :
Maximum  :
Minimum  :
Property :

I think this should be rolled back until we have a better solution.

[ChrisGarty]

Hi @Nazul , is the memory limit being exceeded because of the 40% increase in the size of the resulting dataset or because you can't do a filter on the inital Get-AdminFlow call because some data isn't there (like CreatedBy), or something else?

[Nazul]

That's in that environment, but let's see in another one. A small environment with less than 500 flows (our default environment has over 4K flows).

C:\> $flows = Get-AdminFlow -EnvironmentName $devEnv
C:\> $flows.Count
448
C:\> Measure-Command { $flows = Get-AdminFlow -EnvironmentName $devEnv }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 9
Milliseconds      : 382
Ticks             : 93821269
TotalDays         : 0.000108589431712963
TotalHours        : 0.00260614636111111
TotalMinutes      : 0.156368781666667
TotalSeconds      : 9.3821269
TotalMilliseconds : 9382.1269


C:\> Measure-Command { $detailedFlows = Get-AdminFlow -EnvironmentName $devEnv | % {Get-AdminFlow -EnvironmentName $_.EnvironmentName -FlowName $_.FlowName} }

Days              : 0
Hours             : 0
Minutes           : 12
Seconds           : 12
Milliseconds      : 498
Ticks             : 7324988063
TotalDays         : 0.00847799544328704
TotalHours        : 0.203471890638889
TotalMinutes      : 12.2083134383333
TotalSeconds      : 732.4988063
TotalMilliseconds : 732498.8063

C:\> $flows | ConvertTo-Json -Compress -Depth 30 | Out-File .\flows.json
C:\> $detailedFlows | ConvertTo-Json -Compress -Depth 30 | Out-File .\detailedFlows.json
C:\> dir *.json

        Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a---         7/12/2023   1:07 PM      158090151 detailedFlows.json
-a---         7/12/2023   1:03 PM         513933 flows.json

Time goes from 10 seconds to 12 minutes!

Data size goes from less than 1 MB (501KB) to 150 MB!

No, we cannot filter as we need to go and apply our governance rules to all flows, not just a subset. We could implement some sort of process that applies those rules in batches or other ways to optimize it, but that means we need to apply some sort of reengineering. We shouldn't have to change everything just because of this change. Particularly since it was implemented with the correct notification and timeframe for analyzing and changing everything.

This needs to be rolled back ASAP.

[Nazul]

I created a support case. Hopefully, this can be rolled back until it works correctly, and it gets notified accordingly.

[max81]

doesn't look great.
I'm still busy with other stuff this week. So I will start next week and I have only one week for migration because of summer holidays.

Question ahead: is the documentation for this action correct and up-to-date?

[Nazul]

Any updates about when this is going to be rolled back? We need to be sure we can either upgrade to a new PowerShell module version that does not have this issue (and is using the old API endpoint with the correct data), or that if we uninstall the latest version and install one that is older than 2.0.165 it will still work.

[mzandegiacomo]

Thank you for you message @ChrisGarty. We start to plan the upgrades but as mentioned, we might not be finished until the middle of August.