While reviewing the flows in an environment using the Power Automate Admin Center (PPAC) analytics, it was clear that a small number of flow runs were generating a vast number of API calls!

image of the power platform admin center power automate analytics

It’s likely that a single errant flow is creating all these calls.

The problem is that using the analytics screen, I can narrow the issue down to the 3 flows that are using the SharePoint connector, but which one has generated all those API calls?

The 3 flows aren’t named in the report, but are identified by what initially seems to be their GUID. However, closer inspection reveals these GUIDs aren’t the flow GUIDs that I see in the URL when I look at the flows via their solution in the Power Automate Studio.

There are many flows in the environment and I don’t want to open each one to inspect individually, so how do I track the culprit down?

PowerShell to the Rescue

I can get a list of all the flows in the environment by running the PowerShell command below using the environment’s GUID which I can get from PPAC:

Get-AdminFlow -EnvironmentName 4413416f-b689-ecb0-afe5-76ba7fc0bdf5 -Verbose

This returns all the flows in the environment, a sample of which can be seen below. I can then search for each GUID to get the display name of each of the 3 flows.

image of the data returned from the powershell command

As I now have the 3 flow’s display names, I can open each in Power Automate Studio to track down and resolve the issue.

Directly Viewing the Flow

It turns out that the GUID displayed in the analytics report is the GUID of the Flow outside of it’s solution and I can open each flow directly by using the URL format below:

https://make.powerautomate.com/environments/<Environment GUID>/flows/<Non-Solution Flow GUID>/details

So to open the first flow in the image above, the URL would be:

https://make.powerautomate.com/environments/4413716f-b689-ecb0-afe5-76ba7fc0bdf5/flows/175897d1-16aa-b357-8756-7d3f2b1495b9/details

This is a quicker and avoids the need to use PowerShell. However, beware of editing a flow directly from the URL above, as you will be updating it outside of a solution. Best to use the URL to identify the flow’s display name, and then open the flow from inside a solution for editing.

Happy trouble shooting!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top