Having to build repetitive Power Automate flow logic over and over can be annoying, and a maintenance hassle. But Child Flows are here to save the day - and you some time.
You may have stumbled on the idea of a child flow in Power Automate while browsing the list of actions you can trigger. But what does that do?
In its simplest form, it allows you to call a Flow within a Flow and return a result up to the parent flow (if you want).
This can be a great way to slim down logic that’s happening in the parent flow, but there’s way more to it.
Here’s a few reasons why Child Flows… are the best Flows.
This is a principle that’s learned in the computer science world.
It means: Don’t Repeat Yourself
Have you ever caught yourself building multiple flows that do very similar things? Or even times where you copy/paste steps between flows? This can… work in a pinch.
But the principle establishes the premise that if you’re duplicating code, that code should be pulled out into functionality of its own for a few reasons:
To see what it’s like to modernize your entire organization, download our free guide.Get the Free Guide
One annoying thing about flows that are manually triggered is that it “runs-as” the user who is initiating the flow. That means they need to have ALL the licenses to perform every step of the flow, and their user account will get associated with anything that happens.
The way around this is to either:
We’re obviously focusing on the latter.
Because the child flow only takes defined inputs and is triggered manually, any connections that get configured within that flow work as-is. It doesn’t have to run as the user that calls it like other flows would have to.
Is this “the way to do it according to Microsoft”? Doubtful.
Does it work well? Heck yeah, it does.
Now, if you need to use a Premium Power Automate Connector in one of your flows, you can get by with a child flow and only need to pay for the extra license via the service account. This is why MS probably doesn’t like this advisement. But oh well. We’re trying to save you some money here.
The easiest way to illustrate this is probably with an example.
Let’s say you have some business processes where you need to associate a “client” with an “account” when a flow gets triggered, and I need to get the ID of that client so I can associate it with the account.
You get passed in the client’s first name, last name, email, etc. as inputs to the flow. Sometimes you get a driver’s license number if the system running the flow has it already.
This creates precedence of operations:
This creates quite a few branches that would be a pain to copy and maintain. If this was as simple as “I always get their driver’s license number, just grab an existing client with that number”, yeah, that can be built on the spot pretty easily.
But we want some redundancy and extra checks here. I want my system to be smart enough to take whatever inputs I give it, and spit out an ID. I don’t want to even really consider the logic that’s going on behind the scenes when I’m building the parent flow.
And because I have it separated into a child flow, it’s much easier to view it as a “utility” that can be used to make things nice and simple from the 10,000-foot view.
And the beauty of this benefit along with the first DRY Code benefit, is if new use cases come down the line (maybe we start keeping track of addresses or something and want to look up based on address), there is only one place to adjust the fairly complex logic, and all the parent flows “see” is one extra optional parameter.
Are you sold yet? I hope so… that’s kind of the point of this blog 😬
Well, don’t go running off quite yet, there are a few other things you should know.
Hopefully, this does a good job illustrating why you should try using child flows at your organization. They’ve been super useful to us for all the reasons above and have slightly reduced the headaches involved with Power Automate 😉.
Anyway, there’s so much more to this topic that we could dig into. If you want to know more, leave us a question/comment below!