Personalized Community is here!
Quickly customize your community to find the content you seek.
‘Better Together’ Integration forum available
We're launching a how-to forum where you can learn and engage about how Dynamics 365 integrates with other Power Platform products.
Read about Better Together forum
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
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 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)
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!
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.
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.
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.
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.
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
You know that annoying error you get when trying to populate a lookup field in Power Automate with the Current Environment connector? And you might have found blog posts that the solution is to set the EntitySetName before the dynamic data? Good so far – but how the hell do you find the EntitySetName? Let… Continue Reading →
Business Applications communities