There are situations where you need to call a flow from another flow. For one, a flow is limited to a certain number of total actions (currently 500) and the total number of nested levels (currently 8). If your flow requires exceeding these boundaries, you would need to break it up. For another, breaking flows apart is a good way to break out common processes that are needed across different functions (i.e. refactoring).
Regardless of the reason why you might need to call another flow, there are a couple of different methods you can use to call one flow from another. One of those approaches is fairly straightforward. The other is not.
The more straightforward approach is an adaptation of a method I’ve covered in a pair of previous blog posts. You can call a flow with an HTTP Request trigger.
To call it from inside another flow, you add an HTTP action to your flow that calls the URL created for the child flow. You can use this to call any flow from any other flow. This is the better choice if you are calling a flow that will provide a quick response or if you want to call child flows in parallel, concurrent execution paths.
The biggest downside is that if you are waiting for a response, the call via HTTP can time out and cause your flow to fail. So what do you do if your child flow might take hours or days or even weeks to complete and respond?
Much like how Solutions in Visual Studio let you group related sets of code, the Power Platform provides the concept of Solutions to help you group and organize related flows and other Power Apps content together. Solutions also include an action for calling a flow from another flow that isn’t available in a normal flow called “Run a Child Flow”.
Let’s walk through an extremely simple example of implementing this. In the Power Automate menu, select “Solutions”.
Then, in the Solutions menu, select “New Solution”. Give your solution a Display name. You’ll notice as you type that it will automatically populate the Name field as well. You can leave that or change the name to something else. The biggest difference is that the Name field cannot have spaces in it.
There are two other fields here: Publisher and Version. Version can be whatever you want to put in here and works like standard version numbers for pretty much any software.
On the Publisher setting, you can create a new publisher or you can select one of the default publishers that appear in the list. If you’re going to create your own publisher, note that it won’t immediately appear in the dropdown. You have to cancel the New Solution dialog and restart it after you have created your publisher.
Once your solution is created, you will be presented with a blank solution page and the message “No components found”. So now that we have our solution, it’s time to add components.
For this solution, we’ll add a pair of Cloud flows. At the top of the screen, you’ll see a “New” button. Click on that and you’ll see a long list of items that you can add as part of your solution. Click on “Cloud flow”.
We’re going to add the child flow first so we have something to call. Give your flow a name and set the trigger to “Manually trigger a flow”. Give it a couple of inputs, whatever you want passed in to the child flow. Alternatively, we can use the HTTP Request trigger here as well. But for this example we’ll use the manual trigger.
Whatever else you do in your child flow, the only thing that absolutely matters is that it must return a response to the calling parent flow. The last step of your child flow will be the action “Respond to a PowerApp or flow” (If you used an HTTP Request trigger, then use a Response action instead). Click on “New step” at the bottom and add that action to the flow. You must include at least one output value to be returned to the parent flow. Save and close your child flow.
Here I will point out one of the most annoying aspects of working with solutions in the Power Platform. When you close out of a flow you created in a solution, the site doesn’t return you to the Solution page. It instead returns you to the “My flows” menu item. To get back into your solution, you have to click on Solutions and find and open your solution that way.
Go back to your solution via the Solutions menu item and add a second flow. This will be our parent flow that will be calling the child. Your trigger can be whatever you type you need it to be. At the point in the flow where you want to call the child flow, add a “New step” and search for the “Run a Child Flow” action. Remember that this action will only be available in flows created inside of a Solution.
You will be met with a list of flows in your current solution (including the flow you’re working on currently. Can you say “recursion”?). Select the child flow you created.
When you select your flow, you will see additional fields show up in the action box representing the input parameters of your child flow. Set those as you would any data field to pass into a flow action.
When adding actions after your “Run a Child Flow” step, you will now see the values returned from the child flow as data elements you can work with.
That’s it. Nothing else is needed for this approach. We’ve used a solution approach to calling a child flow. The biggest thing to remember with using this method is that the parent flow will pause while it waits for the response from the child flow, even if that response takes hours or days to return that response.
Here I’ve presented two different methods for calling one flow from another. Each has it’s advantages and disadvantages. Whether you need to reduce the size or depth of your flow, or you just see a good opportunity for refactoring, both approaches can provide you excellent ways of breaking up your flows into multiple pieces.