The child flow feature in Power Automate differs from how the child workflow feature from the classic workflow engine in Dynamics 365 works. This article will take you through how you can build your first child flows in Power Automate and what to expect to be different from what you might be used to.
Start with the Child Flow
Start with the PowerApps trigger.
By using this trigger you have the option to choose the dynamic value Ask in PowerApps which would be information that you want to be passed on from your parent down to your child.
PRO-TIP! Rename your action before using Ask in PowerApps to make it easier to determine in the parent what you are actually asking for (plus it’s looking way less ugly)
Be Careful with what you wish for
Everything you choose to ask for with this action will become mandatory to define in your parent flow – even though you decide to not use it in your child anymore. So be careful with what you ask for.
If you accidentally ask for something or change your mind about an ask, you need to remove the trigger and re-ask about all the fields you really did want. This is a time consuming problem you want to avoid – so plan your child flow well!
How to end
End your child flow with the Respond to a PowerApp or flow action.
Here is your opportunity to send something back to the parent. It could for example be an ID of the record you created in the child flow or maybe a count of something that you ran in the child. Choose the output type that suits your need the best – and if you don’t have a need to send output back to parent – just add a text that says “cowabunga” .
The PowerApps trigger in combination with ending your child flow with the Respond to a PowerApp or flow action is what defines it as a child flow.
Creating the Parent
The parent is quite straightforward just make sure both your child flow and your parent flow is created in a solution. Then you will be able to pick the Run a Child Flow action.
When you choose what child flow to run you get those fields you asked for to be defined in your child as mandatory here (are you not glad now that you named your action properly? 😉).
In your parent flow you can just use the dynamic data output from that child flow run that you defined in your end action in your child flow.
The difference to classic child workflows
So how does this differ from classic child workflows?
The trigger functionality is different to what you might be used to in classic child flows. In classic your workflow could trigger on both CRUD events as well as being a child workflow that could be called from a parent.
In Power Automate your child flow is always just a child flow – and is always in need of a parent – won’t do on it’s own. In Power Automate you use the PowerApps trigger which does not trigger on any other event besides when it get’s called.
2. Child and Parent communication
In classic workflows there wasn’t really much communication between the parent and child. You started your childflow from the parent, it ran as if it was a teenager living on it’s own – not calling their parent to say if it succeeded or not. Also very independent – not needing any input from their parent.
Here’s where the big improvement is regarding child flows in Power Automate. They TALK. So by using the PowerApps-trigger in your child you get the possibility to ask the parent for input.
Asking parent for input and also being able to send context back to the parent opens up for a more flexible usage of child flows than what was possible in the classic workflow engine.
3. Child Failure
If a child flow fails the parent flow will fail too – since it’s waiting for that output to get back to it. This differs from classic where the parent were happily unaware if their child failed and kept indicating everything was just dandy.
Despite most of these headings looking like this is some kind of family advisory post I hope I made my point in showing how much more powerful the child flows in Power Automate is compared to the classic workflow engine.
Using child flows is recommended instead of creating huge complicated flows. To make child flows is to make reusable components and therefor create a more maintainable solution. A thing to note though is that a child flow counts as a flow run – so if you’re low on runs (only applicable if your still on the old licensing model before October 2019) this might not be the best solution for you.
Also take concurrency into consideration when designing solution with child flows, and always choose what is best for your particular scenario.
Take care of your children and parents folks.
PS. If you want to read more about what differs between workflow and flow you can look at this post from last week
When your Dataverse Environment doesn’t show up in the maker portal
Are you as impatient as I am and gets annoyed when you create or reset a Dataverse environment in the admin portal and can’t see it in the maker portal? Well with a couple of clicks I can show you how you go to open your environment and start building solutions in no time.
Great Article !!
Reblogged this on Nishant Rana's Weblog and commented:
Great article- comparing child workflow and child flow
Awesome post. I really love child flows as it’s awesome. They act like mini functions that can return values but one thing that annoys me to no end is the error I get when I try to duplicate/save as a flow to convert to a child flow and then when I try to use it, it throws a error that it’s in the wrong subscription.
I’ve tried adding it to the solution, exporting it and importing it back in but to no avail.
I don’t recogonize that behaviour but I never save as on child flows. What is your use case for that?
It happens normally when I’m building out a flow and as it’s getting longer I realise it’ll be cleaner to split it out for various functions. So instead of copying across all the steps I save as and then remove the bits I don’t need from each flow.
Makes sense. Thanks for bringing that to my attention 🙂 Hopefully there will be a better way of doing this in the future.