Summer ’20 Flow Preview

/16 Comments/in /by

I’m very pleased to again be able to share upcoming new Flow functionality! Preview Orgs can be obtained to try out this functionality.

Complete Flow Trigger Support

We’ve been adding triggers to Flow for the last couple of releases, and Summer ’20 finishes the job by adding support to trigger Flows on both traditional Process Builder-style record change events and platform events. We’ve had to do another evolution of the New Flow window because there are now so many ways to start Flows:

For Record Change events, you’ll be asked to choose whether you want to use the standard triggers that kick in immediately after a record change gets saved (also known as “After Save” triggers), or use the trigger introduced in Spring ’20 that fires immediately before the record saves:

The set of things you can do with a “Before the record is saved” triggered Flow is limited, but it does an extremely fast job performing one of the most common reasons processes are triggered: update a field before it gets saved with some additional information. For that use case, Before Save triggered flows are 10x faster than Process Builder. If you need to do things with related records, though, you’ll need to either use After Save triggered flows or stick to Process Builder. (We’re tracking the handful of features that are present in PB and not yet in FB, and intend to bring them all over to FB)

Flow Debugger Enhancements

This release, the debugging environment gets three useful enhancements:

  • You can now debug your scheduled flows. When you do this, Flow runs against the oldest record that matches the filter criteria.
  • If your flow uses input variables that expect records, you can select a specific record to set them to while running in debug
  • While debugging flows of type Autolaunched, you can enable ‘rollback mode’, which prevents changes from being permanently committed to your data
Record Selection
Rollback Mode

Multilevel Flow Permission Elevation

Permission elevation allows you to give a Flow a consistent level of access that makes it independent of the people running the Flow. That lets you create flows that can be used by relatively low authorization users (like Guest Users) that still do useful CRUD operations on key record types like Case and make use of Apex invocable actions.

Over the last couple of releases, Flow has been adding granularity to its permissioning. In Summer ’20, it becomes possible to anoint a flow with the ability to run in “System Context Without Sharing”. As you can see from the choices below, “System Context Without Sharing” is essentially full access to all data, whereas System Context with Sharing  bypasses object- and field-level security settings, but still respect org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories.

Flow Analytics: Screen Time Duration & Record Count

You can access a pre-built report that shows analytics about your screen flows. Access this report from Report Tab > Public Folder > “Sample Flow Report: Screen Flow”. You can see how many flows are currently running as well as how many have been completed in a specified period of time.

Preview(opens in a new tab)

You can inspect the individual transitions of single flow executions:

You can compare across screen flows and see how many instances (interviews) are currently running:

Automatic Input Retrieval

When you pass a recordId into a Flow from App Builder or a Quick Action, Flow now automatically converts it to a record (this is also known as ‘hydration’).

  • With Quick Actions, you still need to name your the input variable recordId, but you can make its type a Record type like Account or Contact, as opposed to the old Text option. You do not need to do Get Records to retrieve the record.
  • In Lightning App Builder, you will now be able to choose Pass record into this variable. for input variables of type record.

Automatic Output Handling Extended to Cover Subflows and Loops

The last substantial elements that required the use of manual variables have been enhanced to automatically generate output references for use downstream in the flow. In addition, see New Next Behavior to see a small but subtle change to Next behavior that was limiting the usability of Automatic Output handling. Automatic Output Handling is now on by default for all new elements.

For Loop element, the effect of this is to eliminate the need to create a “Loop Variable” in all new Loop elements:

Flow Guardrails

Guardrails are pop-up alerts that warn you about detected issues you might want to address. 

Initial guardrails detect:

  1. Unclosed loops
  2. Database (DML) operations inside of loops

Changed Next Behavior for Screens with Lightning Screen Components

When returning to a screen via the Next transition, Flow will automatically recalculate the inputs of any lightning components on the screen to reflect any changes you made upstream in the Flow.

Previously, if an attribute of a Lightning screen component had both the input and output set in Flow Builder, then on a Next transition, it would reuse the most recently output value from the component and would not recalculate the inputs.

Basically, what this change does is ensure that EVERY time you visit a screen via a Next button, it freshly applies the latest input and EVERY time you visit a screen via a Previous button, the last value you had in the field is restored to it.

Pass Apex-Defined Variables into & out of Flows

The Apex-defined data type affords you a flexible way to represent complex data that isn’t well-modeled by the sObjects in your organization.  Customers often use the Apex-defined data type to represent external web objects, so that they can integrate with external web services either entirely declaratively through Flow and External Services, or with a mixed code & clicks pattern through Flow and invocable Apex.

Now, like with most other Flow-supported data types, you can pass values or variables of the Apex-defined data type into & out of flows and subflows.

Miscellaneous Improvements

  • Revised Help menu provides more contextual, useful help, as well as Guardrails settings
  • Property Editor headers automatically hide unused field to save real estate
  • Field traversal in merge fields and combo boxers now goes multiple levels for Apex-defined data.

Flow Development Enhancements

Custom Property Editors in Beta for both Invocable Actions and Flow Screen Components.

The Send Rich Email sample action from the pilot will be published shortly as an example of how to add graphical user interfaces to your actions:

This easy-to-use Update Field action (to be published shortly), when coupled with the new Record Change triggers, provides for the first time a high quality Flow replacement for Workflow Rules:

Joining the actions, the beta also includes Custom Property Editors for Flow Screen Components. Here’s a preview of the new interface for Quick Choice:

To learn how to build Custom Property Editors, see https://salesforce.quip.com/O6ukAMGhIIdM

Dynamic SObject Support for Flow Screen Components

This allows the creation of screen components that can be passed any kind of records. Eric Smith has already put this to work with Datatable, and the Flowhana now has, for the first time and after years of waiting and effort, a List View component that can be dropped into any Flow to work with any collection of records.

To learn how to build screen components that support dynamic sObjects, go here.

Have questions? Since these are official features, we suggest you post questions to the Automation Trailblazer community.

Finally, for those of you waiting for Sections and Columns and Canvas Autolayout, they didn’t make it into Summer but we are in great shape for the Winter ’21 release.