By Veronique LengelleToday’s post is about choosing one option versus the other, when it comes to triggering our flows. Our Child Flows to be precise… I’ve learned the hard way so you don’t have to! 😅
Manual Triggers
The obvious choice when it comes to creating child flows.
In fact, most blog posts and content out there will show you Instant triggers when talking about child flows. But why is that?
Because:
- Quick to setup: Just choose the instant trigger
- Easy to use: Select input types for different type of values to pass on
- Price: FREE to use!
However, there are a couple of things to be aware of… For starters, the inputs are not covering every data type we’d need.
Where is the Boolean type? If I need to pass on a boolean data type, I need extra steps to convert it before, and most likely use the Text (type) input. Passing an array as input is also not straightforward!
Instant (manual) triggers are also causing issues when it comes to Application Lifecycle Management (ALM) processes. This is the bit I’ve learned the hard way…
I was working on a very complex project with multiple child flows. When it came to move the Solution from one environment to another, the child flows were turned off, and impossible to turn them on! 😳
Sample of error you may get:
Turn on failed. Flow client error returned with status code “BadRequest” and details “{“error”:{“code”:”ChildFlowNeverPublished”,”message”:”The workflow with id ‘<FlowID>’ cannot be used as a child workflow because it has never been published. Child workflows need to be published at least once before they can be included in a published parent workflow.”}}”
Oops! Now that’s bad. Especially when you have 10+ child flows…
Instant triggers might be good for small solutions/projects or when the data type inputs are not complex, but if you want to spend less time troubleshooting or refactoring your child flows, there’s a better way: HTTP triggers.
HTTP Triggers
I already know what you’re thinking; It requires a different type of Power Automate license.
Yes, this is a premium connector. Yes, there’s more setup to do. But the flexibility it offers is totally worth it.
In your Parent flow, you’ll use an HTTP action to call the child flow by passing values in a JSON format. Which is great for data types limitations we’ve discusses before.
When you save your flow, a URL will be generated. This URL is sensitive and has to be treated like a password! That brings me to the next important thing: Security.
If the URLs are sensitive, we don’t want to store their values into flow variables. While It’s highly recommended to use Environment Variables for your Site, Lists/Libraries, Content Types and Views (yes yes, those too, trust me), it’s equally important for your URLs. We can use Azure Key Vault, and create an environment variable of type Secret.
Now when moving your Solution to another environment, your child flows will not face the error above, and it’ll be a relief that you can turn them on 🙂
Other benefits from using HTTP triggers is the ability to start (or test) them directly from the child flow. This means you don’t need to trigger the Parent flow for them to run.
And when it comes to “Run a Child Flow” connection, you don’t have to worry about that either! 😉
Conclusion
In conclusion, manual triggers are great for small projects where you’re happy with the data type inputs it offers out-of-the-box. In contrast, HTTP triggers are more “premium” and Enterprise ready. They do offer the flexibility you need for complex projects with less time spent on troubleshooting/refactoring.
Thanks for reading! 🙂