A few weeks back my colleague gave some feedback on my ‘A Guide to Error Handling in Power Automate Flow‘ article and asked if I had intended for the error handling steps to be encapsulated within a ‘Child Flow’. I scratched my head and replied what a good idea!

So today I have created a second Cloud Flow with the imaginative name of ‘Test Error Handling 02‘ which calls a Child-Flow named ‘Error Handler‘. Both of which can be found within the updated ‘PoC Flow Error Handling‘ Power Platform Solution, which you can download from my Power-Platform GitHub repository.

Why use a Child-Flow?

Imaging you have a number of Power Automate Flows that are critical to your organisation. In my previous article you would have to recreate the ‘Error Handler‘ scope in each Flow, below each critical step. This would take a lot of time and clicking (or copy and pasting*).

Creating a single ‘Child’ Flow means that you only have to create your message template once and then call it as many times as you require. It has the added advantage of reducing maintenance overheads; for example, if you needed to update the message body, then you only have to update one step (compared to multiple steps and flows).

*At the time of writing this article, using copy and paste within Power Automate Cloud Flows is still in preview and can be temperamental.

Creating the Error Handler Flow

The ‘Child‘ Flow; I started by creating a new Instant Flow within the ‘PoC Flow Error Handling‘ solution called ‘Error Handler‘.

I added three input parameters to the manual trigger:

Name	Type	Description
Flow Display Name	Text	workflow()?[‘tags/flowDisplayName’]
Flow Instance URL	Text	concat(‘https://’,parameters(‘Environment Region (sjlewis_EnvironmentRegion)’),’.flow.microsoft.com/manage/environments/’,workflow().tags.environmentName,’/flows/’,workflow().name,’/runs/’,workflow().run.name)
Scope Name	Text	Please enter the name of the last Scope or Step

Note: Two of the descriptions are code snippets required by the Parent Flow(s) to generate the relevant values.

Below the ‘Scope: Error Handling | Send Message’ step I have added a branch where I apply True or False to the MessageSent variable, using the ‘run after‘ configurations: ‘has failed’, ‘is skipped’ and ‘has timed out’ to see if the message was sent OK.

I complete the workflow with a ‘Respond to PowerApp or flow’ step and return the following parameters to the ‘Parent‘ Flow:

Name	Type	Description
Message Sent	Yes/No	MessageSent (variable)
Message Subject	Text	Output (Compose: Error Handing | Subject)
Message Body	Text	Output (Compose: Error Handing | Body)

Creating the ‘Parent’ Flow

I took a copy of the original ‘Test Error Handling‘ Flow, and after renaming ‘Test Error Handling 02‘, add it to the solution.

I then moved the ‘Terminate: Error Handing’ step out and below the ‘Scope: Error Handling‘ scope, before replacing it with the ‘Run a Child Flow: Error Handler‘ step. As with the ‘Scope: Error Handling’, the ‘Run a Child Flow: Error Handler’ step uses the following ‘run after‘ conditions: ‘has failed’, ‘is skipped’ and ‘has timed out’.

The only other significant change was to move the ‘Condition: Throw Error‘ in to a Scope, which was to demonstrate how Scopes could be used within the context of error handling. The same could be done for the ‘Run a Child Flow: Error Handler‘ and ‘Terminate: Failed | Error Handler‘ steps to make them easier to copy and paste*.

Conclusion

I am a big fan of code reuse and considering Cloud Flows are just a visual representation of code it makes perfect sense, in my mind, to implement similar patterns and practices.