Working with Power Automate Child Flows: What are Child Flows?

This article is part of the Working with Power Automate Child Flows series and of the larger Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

As I mentioned in the article on managing large flows in Power Automate, there are two ways of managing large flows by breaking them down; the first is using scopes which allow you to segment a large flow into different sections, but this approach keeps the flow as one large flow and does retain some of the problems inherent in doing this.

The second approach is to break the large flow up into a number of child flows. This method forms part of a typical approach to ALM (application lifecycle management). As well as allowing you to break a flow down into multiple smaller flows, making them easier to understand and maintain, the child flowa approach means these smaller child flows become reusable, so you can use them again and again within different flows without needing to create the same set of steps within every flow. This can be very useful when creating a set of flows with similar purpose, such as a suite of approval workflows, where you need to check the users automatic reply settings on their mailbox to see if a delegation is required.

This re-usability is a key reason why child flows should be used wherever a set of steps would otherwise need to be replicated; by creating and calling the child flow each time, instead of replicating the steps, it is easier to maintain if changes are required in future, but also means there can be no variance in the logic which is applied to this set of repeatable steps.

There are some potential issues around using child flows, which it is probably worth mentioning:

• Child flows are only available within a solution (technically there is a way to use them outside of a solution, but all your flows should be within a solution anyway as part of ALM and deployment to production via a managed solution.
• Child flows are only accessible from within the solution they were created, so you can;t deploy two solutions and have them access the child flow.
• Related to the above point, if you want to use the same child flow in a second solution, you need to manually recreate it as a new child flow within the second solution, as it likely won’t work correctly if you import it (the same is true of the parent flow calling the child).
• Input variables can be passed from the parent flow to the child flow; if you need a lot of parameters passing in, then creating them as an array

As with much else around Power Automate flows, proper planning and design is required before you start building the flows.