What’s next in Salesforce^® automation? Flow Orchestrator and more…

Change is on the horizon. Salesforce^®’s automation journey has taken us down a variety of different roads over the years, and now it looks like they’ve settled on one route to go forward. But where is it headed, what will it mean for you and what is that Flow Orchestrator people have been talking about? All will be revealed. 

Going from three methods to one

Before Cloud Flow Designer was released way back in 2012, declarative automation in Salesforce was achieved via Workflow Rules. Next, Process Builder came along in 2015, giving admins a powerful interface that became a go-to tool for automation in many Salesforce orgs. Later on, in 2019, Flow Builder replaced the Flash-dependent Cloud Flow Designer, and Salesforce has invested a lot of development into it since then. That’s a lot of options, and with all the choices available, it’s no surprise that Salesforce is moving to consolidate declarative automation from three tools into one. 

It was a positive move to relocate automation from Process Builder and Workflow Rules to Flow. However, the path forward for assisting Salesforce users with this change is unclear. Many will face the challenge of converting combinations of workflow rules, processes and flows that have respected the order of execution, or have been built in such a way that automation relies on one automation for another to start. All in all, a lot to consider.

A challenge but also an opportunity 

It may seem like an overwhelming problem. However, we believe it’s a positive opportunity to re-examine existing automation to increase efficiency and reduce complexity. Now there’s an ideal chance to revisit automation strategy and documentation to eliminate technical debt for a cleaner, more manageable org.

We highlighted some flow enhancements in our article on the Salesforce Spring ‘22 Release highlights. New features are coming to flows: some are now generally available and others such as ‘Migrate to Workflow’ are in beta. 

Not everything has been replaced yet, and businesses need to decide whether to take action now or wait for more features to be available. So, with that in mind, let’s look at some of the new enhancements in a bit more detail.

The new Flow Orchestrator

Orchestrator (previously known as ‘Flow Orchestrator’) allows you to create sophisticated multi-step processes that multiple users can interact with via a coordinated combination of screen flows and background flows. Like a conductor, Orchestrator sequences screen flows so that each flow is separately assigned to the correct internal or external user. This is particularly useful for group task lists, advanced approvals where multiple users are required and also with onboarding of employees or project teams. As Orchestrator is an add-on to a Service Cloud licence, it provides a powerful tool to reimagine the case management lifecycle. Please note that it is a consumption-based product sold in yearly increments.

Orchestrator can be a record-triggered or auto-launched orchestration. Autolaunched orchestrations are triggered via an Apex class or third party system through the REST API, or custom button or URL. Record-triggered orchestrations are triggered when a new record is created, updated or deleted in Salesforce. It comes into play after the record has been saved. The flow orchestrations can also now be monitored through the Connect API. 

How orchestration works

The orchestration is a series of stages, steps and flows organised into logical phases. These stages are executed sequentially, as only one stage can be in progress at a time. A stage is completed if it either meets the exit conditions or all steps in the stage are completed. Steps are all flows and are either interactive (require users to intervene) or background flows. Background steps are auto-launched flows that don’t have a trigger and do not require user interaction. Interactive steps assign a screen flow to a user. 

The Interactive steps create work items for assigned users. When a step runs, the orchestration creates a work item with a link to the record page and sends a notification to the assigned user. The Salesforce Admin would have added the Orchestration Work Guide component to the Lightning record page layout. Therefore, when the user clicks the emailed link, they can complete the screen flow from the record page.

The Orchestrator has three main elements. These are a decision element (as already exists in flow builder), a stage (which consists of more than one step) and connectors which define the available path that is taken by the orchestration at run time. It is possible to set entry and exit conditions in addition to the decision element. The entry and exit conditions call evaluation flows which determine whether a step in the stage can be started or whether it should be considered complete. 

Debugging and managing Salesforce automation

What if the orchestration doesn’t work? Well, it is also possible to debug in-progress and failed orchestrations from the Details pane on the Flow Builder canvas. It helps to visualise the orchestration path, variables at particular points and the errors that it encounters. The only thing it does not provide is information about transaction boundaries or governor limits. 

As well as the Details pane debug feature, an admin can view the All Orchestration Runs and Orchestration Work Items lists view. Available from App Launcher / Orchestration Runs or Orchestration Work Items, the list view shows key information about orchestrations that have run. From the All Orchestration Runs list views, it is possible to cancel orchestrations that are in progress. From the Orchestration Work Items list view, an admin can reassign Work Items to another user, group or queue.

It’s recommended to work on an orchestration and associated flows in sandbox. When they have been fully tested, move to the production environment through change sets or via packaging it to deploy.

Run Order of Record Trigger Flows

Having seen the possibilities with Orchestrator, what if your organisation does not have a licence for it? Then there is a way to control the order of record triggered flows by setting the trigger order. Flows have a trigger order value (from 1 to 2000) which prioritises flows with the same trigger (before or after save) on the same object according to the numeric order an admin determines. 

However, when trigger order values are set, the order of execution for the flows for either before or after save is as follows:

1. Firstly, in ascending order for flows with trigger order values from 1 to 1000.
2. If more than one flow has the same trigger order value, then they run alphabetically based on the flow API name.
3. Flows without any trigger order values run in order of their date of creation.
4. Finally, flows with trigger order values from 1001 run next in ascending order.
5. Again, if more than one flow has the same trigger order value, it runs alphabetically according to flow API name.

Of course, flows that are created to act before-save run before the after-save flows.

How does Orchestrator affect the above? It does not necessarily run according to a record save. The lightning component on the lightning record page will take your users through items that may or may not trigger a save on the record directly. Additionally, the trigger order value applies to record triggered flows only. It does not directly affect auto-launched flows (unless they are sub-flows to a record-triggered flow) or scheduled flows. 

An admin can use both tools (if available) to create some powerful automations. What is key is to have a strategy in place for your automation so that it works in harmony – and this is something that VRP Consulting can help with, so get in touch if you need some assistance.

Flow Trigger Explorer

The Flow Trigger Explorer provides a consolidated view of automation processes for a particular object. Accessed via the list view of flows or from an existing flow, the Flow Explorer shows all the flows that are associated with a specified object according to whether the record is created, updated or deleted. This makes it easier to navigate and troubleshoot what is happening with your automation. 

This will become a key tool for admins as the migration from workflow and process builder completes. As you can see from the image, the Flow Trigger Explorer shows flow automations only.

From the Flow Trigger Explorer, an admin can use the drop-down arrow to the right of each flow to access the flow details and versions without navigating away. Versions can be activated or deactivated here and it is possible to see which versions were never activated. The Flow Details window also indicates if the flow was migrated from a workflow and which one.

Migrate to Flow (Beta)

As discussed in our highlights from the Salesforce Spring 22 Release Notes, the Migrate to Flow tool is now available to test. 

So, we dived in to test it out. Firstly, we looked at the Workflow Rules in Setup. Salesforce has added a banner to flag that flows should be used instead of workflow rules. To test the Migrate to Flow tool, we first needed a workflow. One was created with all the possible options that could be used: create a task, update a field, send an email alert or send an outbound message. Additionally, time-based workflow field updates were created on the same workflow. On the first try, the tool rejected the migration. It could not migrate the workflow rule because it contains task workflow actions, and Migrate to Flow doesn’t support this configuration. It’s good to be mindful of this and build those items declaratively in Flow Builder.

We’ll watch this space to see what Salesforce will develop to assist with task migration from Workflow. So, stay tuned for new developments as we learn them. 

Once the task was removed from the workflow, we attempted the Migrate to Workflow tool again. This time, it was successful: it created the flow you can see illustrated here. The field updates are grouped together in the update to the record, the email alert has been added as a separate element, and finally the action to send an outbound message. The time-based element of the workflow has been converted into a scheduled path. The field updates that were to occur after time has passed again were grouped into one update element. All in all, a swift and relatively pain-free experience!

For the Migrate to Flow (beta) tool, the following workflow rules and actions are supported at this time:

Supported rules and actions

• Rules that have field-based criteria
• Workflow Actions:
  • Field updates
  • Email alerts
  • Outbound messages
  • Time-dependent workflow actions
• Rule criteria formula that is set to ‘true’ (unless evaluation criteria is also set to ‘created’, and any time it’s edited to subsequently meet criteria)

Unsupported rules and actions

• Rules that have formula-based rule criteria (save for the exception above)
• Rules that have criteria utilising global variables and/or record types.
• Workflow Actions:
  • Tasks
  • Field updates to record owners.

The current unsupported elements have some sense to them. Where there are custom elements to the workflow rule, it won’t be easily replicated with a simple switch-out of automation tool. Consideration should be given to how each tool works with these elements.

As with all changes to automation, these changes should be carried out in sandboxes and fully tested before deploying to a production environment following DevOps principles. 

Ready for the future of Salesforce automation?

These new features and enhancements are a positive step towards the transition from Workflow Rules and Process Builder to Flow. The flexibility that Flow brings is a great addition to the declarative automation landscape. What we’re still looking for is the ability to declaratively migrate Workflow Actions for tasks and updating record owners. The Migrate to Flow tool for Process Builder is currently pencilled in for the Summer ‘23 release (safe harbour) with all workflow rules and process builders set to edit-only by Winter ‘23 release (again, safe harbour). 

In this changing automation landscape, and with the possibility of shifting deadlines, it’s key to take this intervening time to prepare and scope your organisation’s automation. If you need help and support with your decision making process, change management and/or implementation with your automation migrations and development, we have both consulting and managed services that can assist with your needs – whether they’re great or small. Please get in touch!

Get in Touch

About the Author

Rebecca Heald

Enterprise Architect

As Regional Head of Technical Architecture, Rebecca Heald is responsible for overseeing VRP’s team of Technical Architects across the UK, US, and EMEA. Rebecca drives the strategic direction of the Technical Architecture practice, ensuring high-quality delivery for clients and supporting the growth of the team.