Salesforce Flow Orchestrator is a new automation feature that was made generally available in the Spring ’22 release. It effectively allows to assign screen Flows to specific users to complete. It can be a great tool for complicated processes that bounce between multiple people.

I’ve been using Flow Orchestrator with a few customers as part of my work at Better Partners. In the process I’ve found some things that are missing or confusing that can make things more challenging to use this great feature. This isn’t a list of reasons why you shouldn’t use Orchestrator. Just take these things into consideration as you are planning you’re solution. Many of these are more along the lines of things that I found challenging as I was learning to use Orchestrator.

Flow Orchestrator Missing Features

1. No Process Step overview on record. For example we have “Approval History” that shows who’s been asked for approval and their status. That doesn’t exist on the record. Admins can see it under “work items” list views but it’s not visible for the records that are used in the Orchestration. That means you have to build your own. In my case, I built a custom object and used a background step (autolaunch flow) to create & update records for the interactive steps used.
2. No ability to cancel a Stage or Step automatically. So if something occurs where you need to cancel a step that has been assigned you have to cancel the whole run. I have another post that will be going over how to cancel a run.
3. No ability to customize or disable the automatic “You have an assigned action item in Salesforce” email. You can always send your own, but you can’t prevent the standard email to go out which is less than ideal.
4. No Ability to “build as you go.” All background and interactive steps are autolaunched or screen flows. These all must be built first before you can start building the Flow Orchestrator
5. No “Flow Orchestrator” option from “New Flow.” To find the option to build a Flow Orchestrator you have to click “New Flow” and “All Templates” to even find the option
6. No ability to visually move the steps. There’s a technical reason for this, but effectively if you want to have your steps visually in the order they run, you have to build them to that order to begin with. If something changes in your process later — too bad! Live with it or re-start.

Flow Orchestrator Confusing Stuff

I showed some of these during my Flow Orchestrator Live build.

1. You don’t save a stage, step, or decision. The window opens but there’s no save for these. Just click the x or click outside the window to close.
2. When assigning an Interactive Step to a User, Queue, or Group, you use the Name not an ID. The challenge is that usernames are different between production and sandbox. This means to test in Sandbox will require you to change all the usernames before you deploy to production.
3. You have to have all your Flows built first. Yes, this is a double dip. I found this very confusing when I first started building an Orchestrator. This requires a lot of preplanning so you know what Flows you need for autolaunch and screen Flows first.
4. Passing information between steps. This took some thinking and planning. You basically have a few choices.
   1. Save to a record. Have your interactive or background step to save to the record.
   2. Use Resources marked as Output. The Orchestrator can reference a step’s output resource variables to pass to other steps. You can also create a resource variable in the orchestrator where the default value is the output from a step
   3. If you collect information from a screen flow & need to pass it back to orchestrator, I’ve found creating a resource variable and setting the default to the screen component works. You can also use the assignment to set the value as well. Just make sure that resource is marked for output
5. Flow Orchestrator only has 2 elements: Stage and Decision. The steps (Interactive screen Flows and autolaunch Flows) are part of stages. You have no assignments so everything needs to be outputs of various steps or default of the orchestrator’s resource variable.
6. A Orchestration run is anytime the Orchestrator starts. It doesn’t matter how many steps or stages happen or do not happen. Anytime it starts it’s 1 Orchestration. As of the Salesforce Spring ’22 release, you have 600 Orchestration runs per year as a usage base entitlement
7. Work Guide component will always show the name of the Orchestration and Step. You can’t hide these so always make sure the names you give your Orchestration & Steps are something you’re okay with sharing with your users.
8. The Orchestration Work Items will only show items assigned to the user looking at it – except for system admins.
9. Speaking of the Orchestration Work Items, you can’t do anything with this except look at it. A user can’t perform any actions, but they can click on the “context record.” This will take the user to the record with the Work Guide to complete their assigned Orchestration steps

I still really love Flow Orchestrator for work processes that pass across multiple people and for instances where you need to capture information, but don’t need to save it for later. Orchestrator is great for capturing that information from screen flows, use it for other steps, and then discard it when it’s no longer needed.