.png)
Power Automate provides several ways to monitor cloud flow activity. Periodic emails notifying flow owners of recent failures and the Cloud flow activity dashboard are available. However, we have found that when operating business-critical flows, we need to be far more responsive when a flow fails.
As a result, our Power Automate team at RedCloud has developed a method to quickly and easily log flow failures and notify the flow owner. Admittedly, there are gaps, which I will address later, but this method has greatly improved our responsiveness to failures and identification of core issues.
Setting the table
Perhaps we have a simple flow that retrieves SharePoint items on a schedule and sends one reminder email.
We also want to be immediately notified when the flow fails. To do that, we start creating a Scope to encapsulate the flow failure logging actions. This also makes it incredibly easy to copy and paste across flows.
More critically, we need to set the Log flow failure scope to only run when there is a failure. You do this by changing the scope’s Configure run after settings. By default, all actions run after the previous action ‘is successful’. In our case, we want the scope to run when the prior action ‘has failed’, ‘is skipped’, or ‘has timed out’.
These three outcomes cover scenarios such as these:
Has failed: the scope will run if the previous action has failed
Is skipped: the scope will run if the previous action was skipped because a prior action failed. For example, the ‘Get items’ step failed and the ‘Send email’ action was never initiated.
Has timed out: the scope will run if the prior action timed out. This commonly occurs when an approval is not completed within 30 days.
There are times when you may only want the Log flow failure scope to run after the previous action has failed, so use your own business case to set the run after settings.
Getting workflow details
Now that the scope will run when desired, we need to capture critical flow run details. There is a handy flow expression called workflow().
As you will see, the output provides flow run details that allow you to generate the link to the particular run! I have underlined the critical values.
{
"id":
"/subscriptions/de199c31-4f16-4099-87e6-0b5042c8bada/resourceGroups/F24185AE9B1C4 DAA8E323BC7BA68B0C3-0845F0C2652041ED9E6FB4FCDBA1C2D0/providers/Microsoft.Logic/wo rkflows/5c215c10-fe2e-46e6-a79a-8e8f4d77ed06",
"name": "5c215c10-fe2e-46e6-a79a-8e8f4d77ed06",
"type": "Microsoft.Logic/workflows",
"location": "westus",
"tags": {
"flowDisplayName": "Demo Flow Failure Log",
"environmentName": "Default-f24185ae-9b1c-4daa-8e32-3bc7ba68b0c3", "logicAppName": "5c215c10-fe2e-46e6-a79a-8e8f4d77ed06",
"environmentFlowSuspensionReason":
"Default:2Df24185ae:2D9b1c:2D4daa:2D8e32:2D3bc7ba68b0c3-None" },
"run": {
"id":
"/subscriptions/de199c31-4f16-4099-87e6-0b5042c8bada/resourceGroups/F24185AE9B1C4 DAA8E323BC7BA68B0C3-0845F0C2652041ED9E6FB4FCDBA1C2D0/providers/Microsoft.Logic/wo
rkflows/5c215c10-fe2e-46e6-a79a-8e8f4d77ed06/runs/08585684983136468297173891175CU 86",
"name": "08585684983136468297173891175CU86",
"type": "Microsoft.Logic/workflows/runs"
}
}
Now we can generate a flow run url from the following format:
https://us.flow.microsoft.com/manage/environments/{tags.environmentName}/flows/{name}/r uns/{run.name}
With another simple compose set, we have the flow run url then be logged and enable the owner to quickly access the run!
https://us.flow.microsoft.com/manage/environments/@{outputs('Get_workflow')?['tags']?['environment Name']}/flows/@{outputs('Get_workflow')?['name']}/runs/@{outputs('Get_workflow')?['run']?['name']}
From there, all that is needed is logging the failure into a centralized list. There are numerous data sources you could use, and we have used a few of them. In some cases, we use a simple SharePoint list. In others we log a bug in Azure DevOps or create a record in Dataverse. What is nice about DevOps is that it automatically notifies the bug owner that it has been created. Alternatively, you could create a flow that sends a notification when the failure is logged in a SharePoint list.
Unfortunately, creating this log flow failure function will then mark a run that fails as a success in the log. This may be okay with you, but if you want those runs to be accurately marked as a failure, I suggest then adding a terminate step within the scope.
Wrapping up
With all of this done, you now have a simple method:
Generate a flow run url by using the workflow() function and doing so only when a flow fails according to your criteria
Log failures for immediate action
Create a failure log to analyze and find trends
Let us know what other methods you and your team have used to manage flows!