Winter ’22 Flow Sneak Preview
Here’s a quick preview of the functionality coming to Flow in Winter ’22. Note that this is not the complete list of changes and you should carefully check the Release Notes for changes that may impact your org.
Auto-Layout Now Supports All Flows with ‘GoTo’ Connectors
You can now create flows in Auto-Layout mode that route to previous elements:
When you route a path from an element to a target that already has an inbound path, the canvas represents it as shown above, with a stub path and an incoming ‘connections’ message. With this addition, all flows can be opened in Auto-Layout mode.
Use the New Rollback Element to revert committed changes
To understand this one, first recall that when your flow has a sequence of datatabase operations, like the two Create Records shown below, Flow tries to combine them into a single ‘transaction’ and commit them all at once. In the example here, a Lead and Appointment are being created at the same time in the same transaction. Suppose that one of the database operations fails?
In this example, if the Appointment create fails, and the Lead create succeeds, you’re left with a Lead without an Appointment. Sometimes that’s desirable, but sometimes you want the transaction to have an ‘all or nothing’ characteristic. Now you can route fault paths to a Roll Back element that will ensure that all of the operations in the transaction are properly undone if one fails.
Rollback is currently only available in screen flows because it does not support bulk use cases.
Enhanced List View Choices Provide Information on Triggers
Until now, it hasn’t been possible to see the trigger of a flow when looking at it in the list view. Now you have a Trigger column and also a built-in Triggered Flow list view.
Combine Callout Actions with Record-Triggered Flows with the new Run Asynchronously path
When you create a record-triggered flow, you can now add a pathway for elements that you want to execute slightly _after_ the record operation that caused the trigger completes. This allows the use of callouts with triggers. To enable this, check this checkbox:
This will cause the ‘Run Asynchronously’ path to show up:
…and callouts can be placed on that path. For background: The triggering process opens a new transaction, and the Salesforce platform doesn’t allow callouts to be made while a transaction is open. Elements on the Asynchronous path get executed after that initial transaction is completed. You can also use an asynchronous path to avoid the “mixed DML” error. As an example, in a flow that’s triggered to run when an opportunity is created or updated, use an asynchronous path to update a value on a user record.
Like all asynchronous operations in Salesforce, it’s possible that execution will be delayed by higher priority activity. In general I’ve found that my asynchronous activities almost never get delayed more than a few seconds. You can monitor the progress of asynchronous exeuctions on the Time-Based Workflow page in Setup.
The above images also feature the redesigned Start Element configuration. ‘Fast Field Updates’ is the benefit of what we’ve typically called Before-Save Triggers.
Record-Triggered Flows Can Now Include the Subflow Element
The last big gap in Flow trigger support has now been filled. Note that it currently isn’t the case that the global $Record and $Record_Prior are available automatically in subflows invoked from a record-triggered flow. To get the triggering record ‘into’ the subflow, you need to wire things up manually by 1) making sure that the flow being called by the subflow element has input variables for the record and prior record and 2) on the property editor of the subflow, map the global $Record and $Record_Prior to those inputs.
Scheduled Paths can now be configured with minute granularity
This retires a 13-year-old idea! Not exactly something to celebrate, but good to get that box checked.
Scheduled Paths can also now have configurable batch sizes
This is an advanced feature that allows heavy consumers of flows tune their CPU time consumption and more easily prevent APEX CPU limits from being exceeded.
And finally, Scheduled Paths now use the asynchronous 1 minute timeout limit
Previously flows activated on schedules derived from Scheduled Paths used the standard 15 second timeout limit. Because they’re asynchronous, they now get more time to work.
New Debugger Facilities for Record-Change Triggered Flows
You can now debug selected Scheduled Paths in a Record-change triggered flow:
Additionally, Debugger readouts now feature Labels instead of API Names, to make it easier to correlate the debug data with the visible canvas elements. (You can turn the API names back on).
Finally, In a record-change triggered flow, you can now temporarily change the values that you’re updating on the record that you’re debugging with.
Modify the Labels of the Buttons in the Flow Screen Footer
Of this improvement it has been said: “the lack of this resulted in more custom Flow screen components than any other lack”.
Note that these text fields do not currently support merge fields.
Choiceapalooza: Create Choices by just typing them in
The campaign to improve Choices continues! We’ve long wanted to make it easy to just type choices in rather than have to create special separate resources. Now, the resources are handled in the background, automatically. You can then modify them easily by clicking that pencil icon:
Reactive Screens let components pass values to each other on the same page, triggering instant updates (Pilot)
Traditionally, you could have rich components on a flow screen, but they never talked to each other, and you generally needed the user to click Next to get things to happen. Reactive Screens allow the output from one part of the screen to be fed into the input of another part of the screen, enabling a more ‘single-page application’ feel. Whenever the output of the one component changes, the other component is refreshed, enabling real-time response to user activities. Type in the field of one component and see your changes reflected immediately in another component. This initial release supports the inputs and outputs of Flow Screen Components (and not native components) and doesn’t incorporate formulas into the reactivity, but you can expect more enhancements in this direction.
We’ll get a post together soon that shows the impact of this.
Mulesoft Actions for Flow and Bots are Generally Available
Import your MuleSoft Anypoint Platform APIs in a few clicks with External Services Enhancements for MuleSoft. Select your MuleSoft Name Credentials and let Salesforce do the heavy lifting of importing your endpoints and converting them into actions immediately available in Flow Builder. This was previously in pilot and is now GA.
Salesforce Orchestrator enters Beta
The product destined to be thought of as Flow’s Big Brother is now available for use on all orgs. A separate preview of Orchestrator enhancements is available here.
Flow is now integrated with Event Monitoring
Event Monitoring is a premium Salesforce service that provides tools to track status and evaluate issues. Customers can now see Flow runtime performance metrics in their Event Log Files
Add Einstein Discovery predictions to your flows via the new Einstein Discovery prediction actions
When Einstein Discovery is available, you’ll see deployed predictions surface as choosable actions:
Enhancements to Flow-driven Omnichannel Routing
Omnichannel Routing has been reimplemented as a set of Standard Flows with some specialized Omnichannel Flow Actions. The base functionality is now GA and includes these additional features:
- The Add Screen Pop action opens related records when work, such as a chat, is routed to an agent.
- The Channel-Object Linking action links channel interactions to objects. For example, use it to automatically identify the customer who is calling you.
Start an Omnichannel Flow from the New Flow modal:
Here’s an example of a flow that’s dictating routing based on a number of factors:
Omni-Channel Flow is GA for chats, cases, leads, and custom objects
In addition, support for messaging sessions and voice-call routing is now available in Beta.
For Developers: Custom Property Editors now support the setting of literal values on Inputs that have types SObject, Apex-Defined, SObject[] and Apex-Defined[]
Custom Property Editors (CPE) allow Flow Actions and Flow Screen Components to be created with attractive and useful property editors. Until now, though, the event dispatch mechanism that enables the CPE code to notify Flow Builder of a user-provided value was limited to primitive types if you wanted to store literal values such as text typed by the flow creator into one of your CPE’s text fields. In Winter ’22, you can assemble, in your CPE javascript, JSON representations of any SObject or Apex-Defined Type, or a collection of them, and pass them as literal values. This techique is being used, as an example, by the Salesforce Surveys team to create a new three-dimensional matrix question as a Flow Screen Component. The creator provides labels and values for the question and they’re provided as a literal Apex-Defined object to Flow Builder for storage in the flow definition.
Here’s another use case: Suppose you’re creating an invocable action that makes a callout to order car parts from a web service. The web service expects a JSON data structure that represents the car, its wheels, tires, and rims. To model this, your invocable action uses an Apex-defined type. When admins configure this action in Flow Builder, you want them to have a visual way to indicate which upstream data should be mapped to each tire, wheel, rim etc, so you use your Custom Property Editor to show the image of a car and put picklists where the wheels sit in the image. Previously, there was no way for your Custom Property Editor to assemble the data provided by the user configuring the flow into a complex Apex-defined Type. With this new feature, assemble the information into a JSON data structure matching the format of the Apex-defined type and at it to the payload of of a dispatch event.
For Developers: You can now invoke Invocable Actions from Apex Code
Invocable Actions are wonderful for declarative use inside of builders like Flow Builder and Bot Builder but they are now also powerful ways to tap into reusable functionality when writing Apex code. This feature is in Developer Preview and only works in Scratch Orgs in Winter ’22. You enable it by adding “CallIAFromApex” to your scratch org configuration:
{
"orgName": "my company", "edition": "Developer",
"features": [ "CallIAFromApex" ],
"settings": {
...
}
}
Here’s a sample:
For Developers: Input Attributes in Flow Screen Components can be marked to surface them in Translation Workbench
In a typical Flow Screen Component, some of the input attributes refer to information that is visible at run-time to the user as text. For example, a component might have an input attribute called ‘Label’ and when the flow runs, whatever you enter into that text field is displayed to the user as the label of something on the screen. These have not previously been translatable. Now, developers can add the property ‘translatable=true’ to the description of an input attribute in the LWC meta file. This will cause that attribute to show up in Translation Workbench. Just as it is a best practice to add ‘callout=true’ to all invocable actions that make callouts, so we encourage developers to add ‘translatable=true’ to all of the attributes of their components that result in text visible to end-users running flows.
For ISV’s: Flow Overrides allow a flow in a Managed Package to be customized by a customer without requiring any changes to the package
This eliminates an impediment for packagers trying to incorporate flows into a managed package. The potential is enormous: you can build and sell functionality while letting your customers declaratively customize it in Flow Builder. However, the reality is that the flow that the customer is cloning usually has things pointed at it. Most notably: references from parent flows to subflows. Until now, if the customer cloned a flow, all of those references remained pointed at the original packaged version.
The Override concept allows a flow from your managed package to be cloned as normal. The admin then marks it as a specific override of your packaged original. Flow will ensure that any other flows or resources that use this flow are redirected to the override version.
