Monthly Archives: April 2022

est Error Handling 02: Run a Child Flow

Error Handling using a Power Automate Child Flow

A few weeks back my colleague Chris Langridge 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.

Power Platform Solution: PoC Flow Error Handling

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‘.

Cloud Flow: Error Handler

I added three input parameters to the manual trigger:

NameTypeDescription
Flow Display NameTextworkflow()?[‘tags/flowDisplayName’]
Flow Instance URLTextconcat(‘https://’,parameters(‘Environment Region (sjlewis_EnvironmentRegion)’),’.flow.microsoft.com/manage/environments/’,workflow().tags.environmentName,’/flows/’,workflow().name,’/runs/’,workflow().run.name)
Scope NameTextPlease 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.

Instant Flow: Manually trigger a flow

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.

Cloud Flow: Branching with logic

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

NameTypeDescription
Message SentYes/NoMessageSent (variable)
Message SubjectTextOutput (Compose: Error Handing | Subject)
Message BodyTextOutput (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.

Cloud Flow: Run a Child Flow step

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’.

Cloud Flow: Conditional branching

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.