Power Automate - Child Flows

One of Power Automates great strengths is its abilities to create small, simple yet highly beneficial automations. Other RPA tools often require a high return to get their development investment, Power Automate (Cloud that is) has such a low development investment it can pick up low return opportunities. That said not all opportunities are small and simple, and Power Automate may still be able to deliver a solution.

In these circumstances we often hit some limits of the platform. These are generally:

• No Break Points
• No Start from points
• Browser rendering issues
• Debugging challenges
• Feature updates

To get around this there are Child Flows, which cover all of the above with the added benefits of speed and reusability across the process or multiple processes.

A Child Flow is a manual button trigger flow called from another flow.

For a button trigger flow to be classified as a Child Flow it must have a respond action (just like a flow called from a Power App or Virtual Agent). You must also set the connections to the flow owner, you can't delegate connections and select 'Provided by run-only user'.

Finally you need to ensure it's in Dataverse (solution aware).

The button inputs are passed by the flow, and the respond inputs are visible in the flow as an output. You can use 'Respond to Power App or Flow' or 'Response' actions to return the output data, the Respond is easier to use so recommend that, but Response
maybe better for arrays (though Respond and a Parse JSON works just fine).

Because the code is separated out it means we can run/test just that flow (code part). Thereby creating our own 'run from' and 'break point'. This segregation also allows easier debugging and feature updates, as we can target changes to a smaller code area, we don't need to test the entire process, a unit test will do.

The reusability comes because flows are linear, there is no loop back like on Blue Prism, so if we want to reuse a code block, we have to duplicate it. A Child Flow can be used like a function, called at any time in the flow. Additionally, you can add the Child Flow to other solutions and reuse across multiple projects.

The final benefit is time, if your flow is time critical (e.g. report deadline) then we can use Child Flows to scale out parallel run's at certain points in our flow (multi-threading baby 😎)

There are 2 types of Child Flows,

1. Run (Also known as 201)
2. Respond (Also known as 200)

1. Run

A Run flow is called but is none blocking (async). The flow that calls it does not need to wait until the entire Child Flow has finished before it continues. To do this we have a parallel branch at the beginning of our Child flow that responds immediately to the parent flow.

If this was an API it would return a 201, which means received to process later.

This is useful for long running flows or chain flows (where the Child Flow calls another flow, see here for more info). A good example would be a SharePoint modify then delete, as the file lock can require a long delay)

2. Respond

A Respond is the opposite to Run, we want the flow to block the parent and run it in sequence (sync). This will be because we need the output from the Child Flow in the parent flow.

I have used Response action here just to demo it, you can and probably should use Respond to Power App or Flow

If this was an API it would be a 200, with the response body.

This is great for reusable function, and if we need to know if the Child Flow was successful. An example would be a logic that compares to lists and returns any variances between the lists.

Key Tips

A couple of requirements I always add to my Child Flows are:

Exception catch the entire flow - all of the Child Flow should be in a scope to catch all exceptions; these exceptions should be dealt with within the parent flow (though still fail terminate after respond so we can identify easily in the logs)

Return success/fail - originally, I passed a success/fail code and a message. The message was for the exception reason, but then I realised this was double jobbing, so I removed the success/fail and just have errorMessage, if blank then its successful else I know its failed and why.

Don't use 500 for Response exception - If using Response action do not change Status Code from 200 to 500 or other error codes, as this will make the action fail. We don't want it to fail but succeed with an exception message passed.

Limits on Child Flow calls in loops - API limits are across all flow runs, so if we scale up multiple Child Flows uncontrolled, we can hit throttle limits on our connectors. When calling in a loop make sure the Degree of Parallel is within the Child Flows actions limits

Version output if reused - if your Child Flow is used on multiple flows in different project a version should be passed as an output. That way we can add version checks in our parent flow to stop unexpected errors. For reference we hold the tested/approved version as an environment variable, which is compared with the Child Flow output. If they don't match we email the owner to do some tests. Once confirmed ok the environment variable is updated to the new version.