In a previous module, we introduced the subject of Child FLOs. 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 FLOs. This module focuses on Design considerations - particularly when you’re working as a team.

Child and Callable FLOs (A Review)

If you haven’t already reviewed the previous module on Child FLOs, we suggest doing that before continuing with this section.

As a review, a Child FLO is simply a FLO that is called by another FLO (aka “Parent FLO”)!

Child FLOs work the same as any other FLO, with the exception that they are initiated by the “Child FLO” event card. They’re great for doing things like iterating over a list, crafting reusable series of steps, or even for breaking up FLOs into smaller, more manageable pieces.

Again, for a more in-depth treatment on the basics of Child FLOs, check out Module 209 - Child FLOs


Remember that there are a number of “gotchas” in working with Child FLOs:

  • Turn on Child FLOs
    • A common error stems from calling a Child FLO that’s not active
  • Fields for Child FLOs
    • You have to define them within the Child FLO 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 FLOs 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 FLOs!

Some things you might want to consider doing when a part of a team:

  • Using Child FLOs to route execution to different paths
  • Have many different executions feeding into the same Child FLO

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 FLOs

To close this section out, let’s work through a more advanced scenario that leverages Child FLOs. 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 FLOs we did an example using the For Each card. This is a common card that uses a Child FLO to power looping through lists and objects.

Again, these functions depend upon Child FLOs. 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 FLOs. This is the List Map function.

The Map function converts a list to a new list by running a child FLO 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!


As with other Best Practices, thinking about design of your Child FLOs can set you up for increased efficiency in creating FLOS as well as getting to better overall performance.