Summer 20 for Flownatics

Flow is getting a lot of love in the Summer 20 release. Buried in the summary page for Flow Builder changes is a quote that I think sums up the not-so-secret end goal of all the work going into Flow these days on the platform:

“With Flow Builder, you can do all your automation in one place.”

This is in reference to the fact that you can now trigger a Flow when a Platform Event Message is received, which, while important, does not in my opinion nail the coffin on Workflow Rules and Process Builder entirely, even in concert with all the other great stuff coming out in this release. Still, come Summer 20 I will likely be taking a different approach to some automation logic, looking at Flow as the first rather than last stop on my frequent how-can-I-make-Salesforce-do-this journeys.

One of the most impactful changes coming in this release is the ability to run Flows that bypass user permissions. The best part about this is that it is an option on a Flow-by-Flow basis, and it is a three-part option, allowing the standard behavior of running in the context of how the Flow was launched (User or System), the behavior that came out in Spring 20 of running in System context “with sharing” (meaning respecting record-level access), or, newly, running in System context “without sharing” (meaning bypassing user permissions entirely). The drawback is that admins will have to think very carefully about which to choose and understand the implications of that choice. 

Some of the enhancements continue on the trend of the past few releases of making Flow easier to configure. From streamlining the process of passing in source record information from Actions and Lightning Pages into a Flow to providing configuration tips right in the Flow Builder, creating Flows is getting more and more admin-friendly.

At the same time, though, it is getting more and more powerful. Flows can now be set to perform actions after a record is saved, functionality squarely aimed at pushing Process Builder toward obsolescence, but more potent in this new form.

This after-saved capability is another for the list of things admins will now have to think very carefully about in their setup process. Flows that are triggered by a record create or update can be set to either run before the record is saved or after the record is saved. These after-save Flows will have the same capabilities of auto-launched flows, unlike the before-save flows that have a limited scope.

Considering the full Salesforce order of execution of what is happening for a record will be critical in designing these Flows. The considerations for the Flow itself will be what field values and operations will be available. The considerations for the overall impact of the Flow will be similar to when launching a Flow via Process Builder. It will be more critical than ever to optimize Flows to minimize DML operations to avoid hitting limits. Thankfully, this release also brings a mechanism to analyze some of that in debug logs.

Speaking of debugging, there are some very exciting upgrades to the debugging process for Flows coming in Summer 20. No more opening a record to test with, grabbing the id from the browser bar, pasting it into the inputs, running the debug, and manually reverting the changes in order to re-test. There is now a lookup component on the Flow debug launch screen to search and grab the record to test against. And, for auto-launched Flows, there is now an option to automatically roll back changes (with some limitations.)

There are even more features to check out in the release notes, such as a new ‘New Flow’ setup launch screen and some developer-oriented enhancements that will continue to expand the options for working with Flow.

What’s your favorite Flow feature in the Summer 20 release? Tell me about it on the Trailblazer Community, or directly at me on Twitter @ifitfloats.