Flow Orchestrator Build – Live
Salesforce Flow Orchestrator was Generally Available as part of the Spring ’22 release. Flow Orchestrator isn’t fully documented out yet and I’ve found a few “gotchas” as I started to build these for my customers at Better Partners. So I decided to do a live-stream build.
What is Flow Orchestrator
Flow Orchestrator is basically a meta-flow. It is built in the Lightning Flow Builder and has components to call other Flows organized as Steps in Stages as well as Decision logic elements. Flow Orchestrator is a great solution for business processes where the “work” is being passed back and forth between people or departments. It can be use as an alternative to Salesforce Approval Processes, especially for approvals with complex logic and approval trees.
Flow Orchestrator is a fairly simple feature that can have complex and big impacts. There’s a few things to consider when building an Orchestration.
Flow Orchestrator Considerations
There is one big consideration before you start building an Orchestration. Plan, plan, plan, and plan. Flow Orchestrator uses other activated Flows. This means these Flows already need to be built and active before you start your Orchestration.
Other of considerations:
- Enterprise+ Editions have 600 Orchestrations per year as part of your Sales/service cloud license for each org. More than 600 runs has a cost. Estimate how often your Orchestration needs to run and contact your Salesforce AE if you need more than your 600 limit each year.
- An Orchestration step can be assigned to a single User, a Public Group, or a Queue. Users only see something in the work guide if they have been assigned a step
- Flow Orchestration steps have to be assigned to a record. This is the record id that will show the Orchestration work guide to the assigned user. This means any user assigned to the step needs to have access to the record to see the step assigned to them
Flow Orchestrator Lessons Learned
Other than planning and having all your Flows built ahead of time. Here’s some general things I’ve learned about building a Flow Orchestration.
- Orchestrations have stages, with steps. A step is a Flow. An Orchestration can also have a decision element. Anything Resource other than the triggering record can be set from value output variables of Flows called in a step
- Orchestration Steps can be either assigned to a user or can be run in the background.
- Orchestration Steps assigned to users are screen flows
- When assigning an Orchestration step:
- User Resource= Username
- Queue Resource = API Developer name of the queue
- Group Resource = Group Name (API developer name_ of the Public Group
- Background steps call an Autolaunch Flow and are useful for updating records, getting data & returning that data to the Orchestration as an Output Resource
- Interactive Steps screen flows assigned to users require a Resource available for output to store any Screen component fields. For example, a Radio button on the screen cannot be available as an output. A Resource variable that gets assigned or uses the screen component as a default must be used.
- Orchestrations steps can be started when the Stage “starts,” when a different Step finishes, or when a different Flow returns True