In this article, I share a strategy for proactively informing administrators and support staff when something has gone wrong within their mission-critical Cloud Flows.

By the end of this post, my intention for you, the reader, is to be able to recreate the solution.

We will start by creating a Power Platform Solution and adding environment variables, a single connection reference and Instant Cloud Flow.

Building a PoC (proof of concept) Flow

1) Start by creating a new Power Platform Solution called “PoC Flow Error Handling“. With a few exceptions I almost always create a Power Platform Solution, which has plenty of advantages (out of the scope for this post).

2) Next, add the following environment variables, setting the default and/or current values to match your environment:

Display Name	Description	Default Value	Current Value
Email: IT Admin	IT Admin team members who will manage and support this solution.	it.admin@test.com	dev.admin@test.com
Environment Name	A label used to describe the environment e.g., DEV, UAT or leave blank for Production.		DEV
Environment Region	Get this value from the Flow makers portal		unitedkingdom

3) Add a connection reference for ‘Office 365 Outlook’:

Display Name	Description	Connector	Connection
PoC FEH: Office 365 Outlook	Office 365 Outlook connection reference.	Office 365 Outlook connection reference.	service.acc@test.com

4) Add an Instant Cloud Flow to the solution called ‘Test Error Handling‘.

5) Open the Cloud Flow and add a Yes|No (Boolean) parameter to the Trigger called ‘Throw Error’.

6) Directly under the Trigger, I add the following variables:

Name	Type	Value	Note
FlowInstanceURL	String	@{concat(‘https://’,parameters(‘Environment Region (sjlewis_EnvironmentRegion)’),’.flow.microsoft.com/manage/environments/’,workflow().tags.environmentName,’/flows/’,workflow().name,’/runs/’,workflow().run.name)}	Contains the calculated Flow instance’s URL.
FlowInstanceName	String	Test Error Handling	Contains the Flow instance’s name.
CauseError	Boolean		Used for demo purpose.

7) After variables add a “Condition” step, which is checks the ‘Throw Error’ value:

• If TRUE then set the CauseError parameter to NULL
• If FALSE then set the CauseError parameter to FALSE

Note: setting a Boolean variable to NULL will cause the Flow to error.

8) After the condition, I add a “branch” and a step to each side:

• The “Terminate: Succeeded” step implements the default “is useful” run after condition.
• The “Scope: Error Handling” step implements the “has failed, is skipped, has timed out” run after conditions.

9) All the error handling “magic” happens within “Scope: Error Handling” step:

1. The “Compose: Error Handing | Email Subject” step, builds the email subject and error title.
2. The “Compose: Error Handing | Email Body” step, builds the email body and error message.
3. The “Send an email (V2)” step sends the email to the email addresses set within the “Email: IT Admin” environment variable, with the importance set to high.
4. The “Terminate: Error Handing” step sets the instance of the flow as failed.

Running the Flow

Either run the Flow by clicking on ‘Test‘ within the edit screen or clicking on ‘Run‘ within Flow’s the details page. Next, select the ‘Throw Error‘ toggle switch and then click on ‘Run Flow‘. The Flow will fail as expected and send an email to the address set within the environment variable.

If you would like to test the successful branch, leave the ‘Throw Error‘ toggle switch unselected (false or off).

Summary

I like this technique, because it informs the admin or support directly via an email, which is flagged as high priority, and includes a link directly to the failed instance. This reduces the possibility of an error being missed and saves time locating the cause.

The unmanaged Power Platform Solution can be downloaded from my Power-Platform GitHub repository.

Update

Error Handling using a Power Automate Child Flow

Thank you

Thank you to MacKenzie Bernard for the beer, much appreciated.