7 reasons to use child flows in Power Automate

When you develop your flows inside solutions you have the option to use child flows. But are they worth it?

The 7 Reasons to use child flows

I’m sure that there are more reasons to use child flows. If you find any good reasons, please feel free to add them in a comment below.

For a while I developed my flows, by creating large flows that do whatever is needed. Then I started looking at creating items in for example a SharePoint list that would then trigger a child flow. But ever since Microsoft introduced Child Flows, I’ve liked to use them as much as i can.

In general the reasons why I would use child flows fits within one of the following categories:

1. Performance
2. Debugging
3. Reduce the number of connections needed by apps
4. Error reporting
5. Detailed Error Handling
6. Reduce the number of step levels
7. Simplify flows

Performance

Sometimes flows hit the connector limits and you might see errors like 429 rate limit exceeded reported by your flow. That is if you are lucky.

Just imagine running a flow for many hours only to find out that a SharePoint action is retrying as it has hit a limit. When actions are hidden away in Apply to each steps, or even worse within multiple nested apply toe each steps you will find that your flow could do with a bit of speeding up.

When the steps inside the apply to each are moved into child flows the flows are actually run lot faster. All you have to do is add a run a child flow action.

Does this means that all steps inside an apply to each should be replaced by a Run a child flow? Well, I would consider it if the steps inside the apply to each are more than just a couple of compose actions.

Debugging child flows

In the Performance section we already saw that it is impossible to debug a large flow if you have an apply to each at the top level of your flow. with child flows this is a lot easier.

First of all in my child flow I could see all the failed flows and the succeeded flows quite quickly. Or I could of course implement the try-catch pattern on the child flow and the parent flow and email any failures to myself.

The important thing to note is that, while my parent flow is running, I can look at each child flow run and investigate any issues.

Reduce the number of connections needed by apps

When you connect with your flow into SharePoitn, or SQL or anything else you will find that if you run this flow from a app in Power Apps that users have to give consent to use a connection. You could use the Run Only users setting to change the way the connections are setup for your child flow.

So just imagine that you are connecting to SQL through your flows. If you do that in the flow that is called form your app directly then you will find that SQL is added to your app connections.

But if you configure the connections used then you can avoid this.

Error Reporting

Earlier I already mentioned the Try-Catch pattern. When you sue child flows you could use the same pattern for the parent and child flows and then email yourself with any failures. While you are developing and testing your flow it will make it a lot easier to find all the failures as the failures are finding you.

If we have another look at the earlier 517 items in my apply to each then stepping through the failures is just about doable. But if the flow is complex and inside the apply to each there is a switch that processes items depending on a status of the item then it can be difficult to figure out that flows are only failing for item with for example an approved status.

Detailed Error Handling

The standard try-catch pattern will handle the errors of a flow, but if you want to get the errors reported for a section of your flow then implementing sub-try-catch patterns can quite quickly clutter your flows.

By creating a child flow, it will feel not more than expected to handle the errors for each of the child flows.

Reduce the number of step levels

When you create a flow with too many nested actions you might get the following error:

The power flow’s logic app flow template was invalid. The template actions ‘Scope_11’ are nested at level ‘9’ which exceeds the maximum nesting limit of ‘8’.

You could see these kind of errors when you use the scope actions but also with apply to each or condition steps.

Although most apply to each steps you might be able to avoid sometimes your flow just has to have those nesting of steps there. Especially flows with many conditional logic build in will require a solution. Well, child flows once again can bring that solution.

Simplify flows

Have you ever worked for many days on a flow and your flow now contains hundreds of steps and you exactly know what each step is about.

Then you explain how your flow works to a colleague and they just can’t get it. By making more smaller flows it automatically becomes easier to understand each part of the flow. Then as your main flow calls child flows you will find that the main flow also becomes easier to understand.