Spring ’20 Flow Feature Preview

I’m pleased to share some of the upcoming highlights of Spring ’20.

Trigger on Record Change Events

Flow Builder now allows you to trigger on record changes, but there’s a catch: in Spring ’20, our support extends to “Before Save” triggers but not “After Save” triggers. The practical ramification of this is that when you trigger on a record change in Spring ’20, you’re going to be limited in the Flow elements you have access to. Here’s what the palette looks like:

Note the absence of Update Records and Create Records. “Before Save’ triggers require a bit of a shift in thinking. The best way to think about “Before Save” triggers is that they allow you to do one thing really well: modify the record that caused the trigger to fire. The key is understanding what’s implied by the words “Before Save”: Flow gets notified when the triggering record is starting to get saved, giving you a chance to make changes to that specific record before the save actually happens. The saving will happen automatically after the flow ends, and so there’s no Update Records.

Because of this special location in the save order, you get positive and negative effects. The main positive effect is performance: Before-Save triggers carry out field updates 10x faster than the standard Process Builder trigger (which is an ‘After-Save’ trigger). The downside is that you don’t get access to Actions and Subflows and you can’t update related (or unrelated) records.

Access the new triggers by double clicking on the Start element in Autolaunched Flows:

We’re working on building out additional triggering capability for delivery in 2020.

Flow Simplification – Automatic Field Discovery and Automatic Output Handling for Actions and Create Record

Flow Simplification is a major multi-release campaign that focuses on making flows easier and faster to build. In Spring ’20, the big announcement is the elimination of the much disliked requirement to specify, in the Get Records element, the entire set of fields that you want to use later in the Flow. That’s over now. Flow automatically detects the fields you use and makes sure to retrieve them. Note that you can still choose to specify these fields manually, and for existing flows, we stay in this new ‘manual’ mode rather than try to do any conversions.

Automatic Output Handling was introduced in Winter ’20 for Get Records and screen components. It is now supported in Actions and Create Records as well.

Invocable Actions can use Generic SObjects with Flow

This enabling technology allows the construction of invocable actions that are designed to operate on any sObject, or any collection of sObjects, that are passed in to them. As a non-developer, you’ll experience the benefit of this in the form of a range of highly-useful new Flow Actions that work on any collection you throw at them. Here are some unofficial actions that we’re experimenting with:

Note that in the image above, although some of the actions are labeled with the word “Account”, those actions are actually called things like Sort Collection and Remove First Record, and can be used in the next flow over against Leads, or your custom objects. In most cases, you _can_ already do these things in Flow, but you often have to set up loops, assignments and updates, and these actions eliminate all of those steps.

As a user of these actions, you play an important role in declaring which specific Sobject or SObject type you’re going to use for this particular action.

For example, in the Flow above, the Sort action has been configured to sort accounts. Suppose that you want to use it to sort a custom object called BakedGoods__c. When you drag it onto the canvas, you start by declaring the specific objects you’re going to assign to each generic attribute. You initially see this:

The declaration has to be completed before the rest of the inputs and outputs are displayed:

An unmanaged package of collection actions is available for installation here on Spring ’20 orgs.

Invocable Actions can provide Custom Property Editors (PILOT)

You will be able to request from Support that your org be enabled for this pilot, which allows invocable actions to use custom property editors. In the slide below, you can compare the baseline, one-size-fits-all property editor that is provided to all actions with a custom property editor built for an Update Field action:

Internal Salesforce teams are already working on sophisticated applications of this, such as this specialized Email action being built for a marketing application that uses Flow:

Run Flows in System Mode

Set your flow to run in system context with sharing. The flow still respects org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories, but it ignores object permissions, field-level access, and other permissions of the running user.

Additional Goodies

Multi-level Field Traversal

You can now traverse through multiple levels of related records/lookups in Flow Builder popup menus:

Deactivate from inside of Flow Builder

Conditional Field Visibility now immediately detects newly created screen fields

Improvements to Keyboard Shortcuts – Click on the canvas and type ‘/’ to see the updated list of available shortcuts

Improved searching in the Toolbox

Subscribe
Notify of
guest
3 Comments
Inline Feedbacks
View all comments
Eric Smith

I’m looking forward to working with Custom Property Editors. I should be able to greatly simplify the usage of many of my generic components.

Chris V

Amazing additions. The flow team has been killing it lately. So much added value to your customers. I know some of these enhancements are to make it easier for new flow builders, but they are amazing for experienced flow antics as well.

Will the generic object support allow someone to create a SOQL query entry and and a objection collection output. I can eliminate so many loops and weird collections if I had the ability to do a SOQL input for get records

eyal kama

Thanks for sharing. Great enhancements.