In a previous module, we introduced the subject of Child Flows. This module focuses on Design considerations - particularly when you’re working as a team.
Course Material
In a previous module, we introduced the subject of Child Flows. This module focuses on Design considerations - particularly when you’re working as a team.
Child and Callable Flows (A Review)
If you haven’t already reviewed the previous module on Child Flows, we suggest doing that before continuing with this section.
As a review, a Child Flow is simply a Flow that is called by another Flow (aka “Parent Flow”)!
Child Flows work the same as any other Flow, with the exception that they are initiated by the “Child Flow” event card. They’re great for doing things like iterating over a list, crafting reusable series of steps, or even for breaking up Flows into smaller, more manageable pieces.
Again, for a more in-depth treatment on the basics of Child Flows, check out Module 209 - Child Flows
Gotchas
Remember that there are a number of “gotchas” in working with Child Flows:
- Turn on Child Flows
- A common error stems from calling a Child Flow that’s not active
- Fields for Child Flows
- You have to define them within the Child Flow first before they show up in the parent!
- If you do create a card, you can easily create a new card to pass to the same Child.
Design Choices
This section is key for those who are developing Flows as part of a team. Just as software developers have coding standards to guide them (such as naming conventions, check-in/out systems, etc.) you similarly may want to consider implementing some Best Practices for your Child Flows!
Some things you might want to consider doing when a part of a team:
- Using Child Flows to route execution to different paths
- Have many different executions feeding into the same Child Flow
It will also be helpful to decide as a team how to design - because if you have multiple people managing you’ll know what to expect to design.
Advanced Child Flows
To close this section out, let’s work through a more advanced scenario that leverages Child Flows. We’ll do this in two parts.
The scenario:
In Salesforce, I need to get all the opportunities assigned to a specific owner. On each of the opportunities I need to know the opportunity ID, name and description.
For Each / For Each - Ignore Errors
In Module 209 - Child Flows we did an example using the For Each card. This is a common card that uses a Child Flow to power looping through lists and objects.
Again, these functions depend upon Child Flows. They contain the logic that drives the For Each card.
- For Each:
- When it’s important that list items processed in order
- Processing stops if error happens
- For each - Ignore Errors:
- The “For each - Ignore Errors” card is similar, but is used when you want looping to happen asynchronously. In other words, the process shouldn’t stop if there’s an error!
For an practical exercise, proceed to Exercise 304-1!
List Map (Advanced)
Building upon this, there’s another great function that lies at the intersection of Lists and Child Flows. This is the List Map function.
The Map function converts a list to a new list by running a child Flow for each item in the list.
With the Map function, the output list always has the same number of items as the input list. This means that I can input a list and return a new list that’s been processed.
For an practical exercise, proceed to Exercise 304-2!
Summary
As with other Best Practices, thinking about design of your Child Flows can set you up for increased efficiency in creating Flows as well as getting to better overall performance.