Flow: Run a Child Flow

While scrolling on my Twitter feed I found this piece of amazing news in how to run a child flow.

In @MicrosoftFlow ‘Run a Child Flow’ action is finally here! No more duplicate logic across multiple Flows. #Microsoft #MicrosoftFlow #PowerPlatform pic.twitter.com/DG3raK81EY

— Satyvir Jasra (@SatDevir) October 25, 2019

Best practices dictate that we should only do something once. It 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 (and are workarounds) and there was no good solution to call other Flows using them as “Functions”, aggregating logic that can be used, changed and maintained in a single place.

Until now.

There’s a new action that allows just that. The “Run a Child Flow”.

This action allows you to call another Flow and even pass the arguments to it. Awesome, so far, but there’s a caveat.

The caveat

This is only available if you create a “Solution”. I’ll go into further detail in the future on what is a “Solution”, but for now, 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.

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. Again, I’ll go into much more detail regarding “Solutions” soon in another post.

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, 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:

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

Create the other Flow

Pick the “Run as Child Flow”

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 re-use the connections defined, the meaning that you cannot use your Global connections defined in the “Data > Connections.” It’s unfortunate, but I can understand why. The Flow needs to run in a contained context, so all need 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.

Conclusion

Overall this feature is amazing. I will still need to use the old “Request and HTTP Post” solution, but at least now I can gather everything under a “Solution” and have the Flows called much more cleanly.

Have a suggestion of your own or disagree with something I said? Leave a comment or interact on Twitter and be sure to check out other Flow-related articles here.

Photo by Deva Darshan on Unsplash