This action, when it was introduced, it was a reason for joy from the community. Previously we only had the possibility to run other Flows using the Request Trigger. The Request Trigger is a premium connector, so it prevented people from using it, so there was no solution. The “Run Child Flow” action does exactly that. Runs another Flow inside your current Flow. You can pass arguments and also retried arguments, but there are some caveats. Let’s first dive into it and explore its features.
Where to find it?
You can find it under “Built-in.”
And then pick “Flows.”
Here’s how it looks like:
Let’s start with a simple example, but first, let’s create a “Child Flow” to call it inside our example.
This Flow will receive a few arguments and save them into a SharePoint list. If you several Flows that save to the same SharePoint List, this is a better way to save the data. There a few advantages:
- If there’s a change in the SharePoint list, you only change your “Child Flow” and not all of them.
- You can do data cleaning and transformation. All “parent Flows” will provide data but will always save it the same way.
- You can validate if the data is correct. If a rule changes, then you only have one place to change it.
So let’s call our Child Flow.
As soon as you pick it, you’ll get the Child Flow options to fill in.
But when you try to test the Flow, you get the following error:
Update the child flow for action 'Run_a_Child_Flow' to end with a response action. Update the child flow for action 'Run_a_Child_Flow' to not use 'run-only user' connections.
There are 2 reasons for the two error messages:
- You need a response from the child Flow. You need it to reply with something, even if your Flow doesn’t need a reply (like our case).
- The connections don’t go from the parent to the child, so you need to define them in the child flow. It would help if you embedded” the Flow’s connection to use it when it’s running “inside” another Flow.
Let’s fix the second issue first:
In the Child Flow, you need to edit the “Run only users.”
And then pick a connection.
This solves the second issue, but what about the first? To do that, we need to use a premium connector called “Response.”
I know what you’re thinking, and the answer is not good. If you don’t have access to premium connectors, you can’t use this feature, and it’s unfortunate, I know.
Child Flows can be Requests.
You can also have a request as a Child Flow. Let’s look at the same Flow as a Request (requires premium connectors).
The same concept applies as before, and the “Call Child Flow” action will display the parameters. It would help if you also had a “Response” action to be able to run the Flow:
The response is 200 (OK), but it can be anything you want. You can also provide a JSON Body with return information to the parent Flow.
Besides the ones I’ve mentioned before, there’s another limitation. The “Call Child Flow” action can only be used in solutions. Consider solutions as groups of Flows, Power Apps, Connectors, and more that have versions and can be run in the same context. I’m oversimplifying, but It’s the way that we can do Application Life Cycle management. Microsoft explains it further in detail, and I’ll write about it in the future.
Here are some things to keep in mind.
Be careful making changes.
Being able to do changes in one place and propagate to all other Flows is both a blessing and a curse. You can fix a bug in multiple Flows or introduce one also. Be very careful when doing changes because you’re potentially going to impact other Flows, some of them not developed by you.
Please keep it simple
The child should have only one purpose and do it well. Child Flows are “black boxes” where something goes in, and something else comes out. Debugging them is hard to keep them as simple as possible. It’s better to break tasks into multiple “Child Flows” than having a big one that returns unpredictable results.
Return errors also
If there’s an error with the Flow, the data, or something else, return something else than 200. It’s important to deal with errors, and always returning the default 200 won’t do you any good. Use the body for proper error messages so that the parent Flow can deal with them. The errors could be things like:
- The data provided is incorrect or fails the business logic
- You’re trying to insert something that already exists
- You need the data formatted in another way
Not always the errors are something that broke, but something that is not correct.
The response should follow conventions.
Returning a random number in the response is possible but not advisable for two reasons:
- There are conventions for the status codes. Conventions help us all “talk the same language,” and in this case is essential that if you return a 401, it means that it’s an “Unauthorized” error.
- Other people will use your Flow. If you don’t have strong documentation (and what company has documentation for Flows?), other people will only know what you’ll return, and that’s it. But if they see a 401, they know what that means and can take action to solve it.
Don’t invite your own error codes unless you have to. If you need, put internal error codes in the body of the message with a description of the problem.
Don’t call child Flows inside of Child Flows. This will be tempting when you realize that you can have one big child Flow that “orchestrates” all the others, but you’ll have a hard time later. It’s hard enough to know what’s wrong when a child Flow returns something you don’t expect. It gets a lot worse when you try to complicate things. The mindset is always the same. Keep things as simple as possible.
Name it correctly
If a Flow is meant to be used as a “Child,” indicate that in the name somehow. I like to name mine “AUX: <Name>” to know that it’s doing something that other Flows share.
Always add a comment.
I always add this recommendation because it’s the most important one. All actions should have comments describing what they do. I recommend also having scopes to compartmentalize the actions so that it’s easier to understand what a Flow is doing.
Use them wisely but use them.
Don’t go overboard to create Child Flows for everything in case you’ll need that feature in the future, but don’t put everything in the same Flow. The worse thing that you can get has a Flow with a bunch of business logic and needs to replicate the actions to another Flow.
Back to the Power Automate Action Reference.