Category: Power Automate

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.

As I have a number of articles to write on Power Automate child flows, I’ve decided to break these out into a sub-series of the main Working with Power Automate series; they will appear as posts within both series in the order written, so you can easily access and read them from within either.

The series index, below, will automatically update if you’re reading the original article on azurecurve | Ramblings of an IT Professional. If you’re reading elsewhere, the original article, which will update automatically is here.

This article is part of the 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.

Over the last couple of articles of this series, I’ve described scopes and shown how they are used.

That’s fine for the basics, but there are a few best practices I try to follow when I use them.

Not everything needs to be in a scope, so try to avoid going overboard. I would only add a scope when there are several related items, such as the document handling on OneDrive I showed in the example article I linked above.

Actions I would not put into a scope would include loops (called Apply to each in Power Automate) and calls to child flows (called Run a Child Flow) as well as the responses to a child flow.

Like all actions, I would recommend renaming the scope action to include a brief description of what the combined actions in the flow are doing and if more detail is required add a note, which is done by clicking the ellipsis button on the scope heading and clicking Add a note.