Flow: Run a Child Flow

Best practices dictate that we should only do something once. It always bothered me that, if I wanted to re-use logic from Flow to Flow, I needed to do one of 2 things:

1. Duplicate the steps. Horrible solution since it's a nightmare for maintenance. Gave up this quite quickly.
2. Request trigger. Another solution would be to use a request trigger and call the Flow using an HTTP Post or Get Request.

Both solutions look like (and are) workarounds, and there was no good way to call other Flows using them as "Functions", aggregating logic that can be used, changed and maintained in a single place.

The "Run a Child Flow" action does exactly that.

This action allows you to call another Flow and even pass the arguments to it. It's also the way Power Automate itself recommends you get around the 500 actions per Flow cap and the 8 levels of nesting cap, since a child Flow starts a fresh budget of its own. Awesome, so far, but there's a caveat.

The caveat

This is only available if you create a "Solution". Think of it as a logical grouping of Flows (but not only Flows) in a nice package. If you try to find that action while building a Flow outside a Solution you won't find it. I can speculate why, but for now, let's use it and have some fun.

Two things are worth knowing before you start. Solutions need a Microsoft Dataverse database in the environment. Your default environment gets one automatically, but for any other environment an admin has to attach it first. And the child Flow has to use the "Manually trigger a flow" trigger. Other triggers were allowed in the early days, but Microsoft has since narrowed the official guidance down to this one, so if the Flow you want to call doesn't show up in the picker, that's the first thing to check.

How to use it?

Let's start with the "Solution".

Create the Solution

You can find the "Solutions" area in your side menu:

Name it

In this case, I prefer to use the predefined publisher (text is in Portuguese but you should see it as "Predefined Publisher for orgXXXXX"), but you can create a new one.

Add a version

Note: The version should be in the X.X.X.X format. For more details, check this article regarding version rules and best practices.

We have an empty "Solution".

Create the Flows

First, let's create the Flow that will contain the logic that we'll reuse.

As mentioned before, a "Solution" is more than a group of Flows, as you can see above, but let's focus on the Flow for now.

To demonstrate, we'll create a Flow that receives an input, trims it with the "trim" function, and returns it back. I know it's simple and it's just for demonstration purposes but you could think of a Flow that parses texts based on your company's naming conventions, for example. This would keep consistency and would be useful in many instances.

Here's the flow:

To hand the value back to whoever called us, we use the "Respond to a PowerApp or flow" action. Without it the child Flow runs happily but returns nothing, and Power Automate will refuse to use it as a child Flow at all.

Now let's call it. For that, we'll need a new Flow. The same steps apply.

Create the other Flow

Pick the "Run a Child Flow" action.

Let's see the result:

Looks good.

There's another caveat

Sorry but I need to show you the full Flow to mention another caveat. The child Flow needs to have embedded connections, meaning that you cannot use the global connections you defined in "Data > Connections". It's unfortunate, but I can understand why. The Flow needs to run in a contained context, so everything needs to be defined in the same Flow. You need to take this into consideration if you want, for example, to send an email in the child Flow.

There is a small exception that saves you some work. Built-in actions and the Microsoft Dataverse connector are exempt, so it's only the other connectors that you have to pin down by hand. To do that, open the child Flow's details page, find the "Run only users" tile, and select "Edit". For every connection listed, switch it from "Provided by run-only user" to "Use this connection (name of your connection)".

If you skip this step, saving the parent Flow fails with a message telling you that the Flow "cannot be used as a child workflow because child workflows only support embedded connections". It's a mouthful, but now you know exactly what it's asking for. Microsoft still confirms in the current documentation that connections cannot be passed from the parent Flow to the child Flow, so this one has been with us from the start.

Non-intuitive behaviors

A failing child Flow runs five times

This is the one that catches people out. The "Run a Child Flow" action ships with the default retry policy, which is 4 retries. If the child Flow fails, it gets called again, and again, until those retries run out. That's 5 executions for a single run of the parent, and each one does whatever the child Flow does, including the side effects. If your child Flow creates a file or sends an email before it fails, you get five of them.

This behavior is widely reported by the community rather than spelled out in the documentation, so it's worth testing a deliberate failure yourself before you trust it in production.

A Flow cannot call itself

Recursion is off the table. If you try to have a Flow pick itself as its own child Flow, Power Automate refuses to save it and tells you that Flows cannot invoke themselves as child Flows. People do work around it by putting a second Flow in the middle (A calls B, B calls A), but be careful. That only ever terminates if each level has less work to do than the one before it.

Errors live in the child Flow's run history

Every call to a child Flow is a run of its own, with its own entry in its own history. When something goes wrong, the parent will tell you that the action failed, but the interesting detail (which action broke, and why) is over in the child Flow. If you want the parent to actually understand the failure, return it explicitly. Add a status output to your "Respond to a PowerApp or flow" action and check it in the parent, or use "Terminate" with a status of "Failed" so the parent fails too.

Build the parent and the children directly in the Solution

Create both Flows inside the Solution from the start. Microsoft lists it as a known issue that importing an existing Flow into a Solution "might get unexpected results", and this is exactly the kind of thing that works on your machine and then falls apart when the Solution moves to another environment. It costs nothing to start in the right place.

Limitations

No arrays or objects

The inputs on the "Manually trigger a flow" trigger and the outputs on the "Respond to a PowerApp or flow" action only cover the simple types: text, yes/no, file, email, number and date. There's no array and no object. When you need to pass a list or a structure, the usual trick is to send it as a text value containing JSON and parse it on the other side with the "json" function.

The parent waits, for up to 30 days

The parent Flow blocks on the child Flow until it finishes. The limits documentation gives a run duration of 30 days, which is your real ceiling here. There's also a 120 second limit on responding, so if the child Flow needs longer than that, respond first and let the rest of the actions carry on running afterwards. That's a supported pattern, not a hack.

Child Flows don't save you any requests

It's tempting to think that moving actions into a child Flow makes them cheaper. It doesn't. Every trigger and action in the child Flow counts as a Power Platform Request just like anywhere else, and the child Flow is measured against the parent Flow's limit rather than its own. Child Flows are for keeping your logic in one place, not for getting around quotas.

Final Thoughts

Overall this feature is great. Being able to keep shared logic in one Flow, and call it from everywhere else, is exactly what was missing. The Solution requirement and the embedded connections take some getting used to, and the retry policy deserves a look before you go live, but none of that takes away from how much cleaner your Flows get once you start using it.

Photo by Deva Darshan on Unsplash