3 Reasons Why Child Flows are the Best Flows

Ok, What’s a Child Flow? 

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. 

1. DRY Code 

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: 

• You get one source of truth for logic that SHOULD be consistent across processes in your organization 
• Need to update the logic? Maybe change a field name? You only have to adjust it once - no tracking down the duplicates in other flows. 
• It makes it way easier to scan/understand from the parent flow perspective. Note that this idea can also be achieved via the “Scope” block of a flow (this bundle's multiple steps together that logically make sense to group together). 

Let's say I’m collecting photos across eight forms and would like to upload them to a SharePoint library, but it requires six steps just to process the image data and upload. (I hope this isn’t reminding you of elementary school arithmetic.) Rather than writing an individual flow for each form that works its way through the same six steps, I could create a single child flow instead. I would have one extra flow at the end, but 34 fewer actions! Now, instead of eight six-step flows, I have eight single-step flows and one six-step flow. That’s a lot of time saved, and if I need to use this process for additional forms in the future, it’s scalable! And if I need to make a change to my process in the future, I don’t need to make it in eight places, just one.

2. Service Accounts 

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: 

• If you’re triggering via Power Apps, use the Power Apps V2 trigger which can be configured to “run as” another account – check out Reza Dorrani’s video on the topic 
• Build a Child Flow 

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 could get by with a child flow (read between the lines: and only need to pay for the extra license via the service account), though I imagine this would be frowned upon by MS for that reason. Just don't abuse this power, and only use it when reasonable. In our case, we've used it to create a task for our team in DevOps (which is a premium connector), and we don't want to give every user access to our boards. So it's completely appropriate to have a service account handle that for us.

Let's give another reasonable example: I want to store information in a SharePoint list that users submit through my canvas app, but I don’t want to give them access to the list. When a user runs a flow in a canvas app, it uses their connections to run it, so if the triggered flow does the work of uploading information to the list, the users will need access. And that’s the beauty of the child flow, as long as multiplexing is not violating your license agreements, you can let another user or service account be the run-as user for the flow uploading the info.

3. It’s Easy to Add Extra Logic That Would Take Forever to Duplicate 

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: 

• Do I have the driver’s license number as an input? Look up the existing client based on that number. 
• If I don’t, let’s look them up by first name/last name/email to see if I have them in the system already. 
• I didn’t find them… how about we just create a new client and pass back the ID that gets created. 

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. 

A Few Gotchas 

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. 

• ONLY use child flows in a solution. It’s possible to use the HTTP Connector directly outside a solution, but that raises security concerns. If you want to learn more about environments/solutions, check out our blogs on Environments and Application Lifecycle Management. 
• Child flows depend on the HTTP Connector. If your administrator has disabled HTTP Connectors, you won't be able to use them. Ping your Microsoft rep and point them to this information 
• You have to create the parent flow and the child flow directly in the same solution. You can't just import them in. 
• Passing in variables can be annoying if you have a bunch of data to send. Using a JSON string can help. 

Wrap Up 

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!