Here at HQ we are feverishly working on presentations and demos for next week. The show promises to have a record-setting amount of Flow and Next Best Action content. Sam Reynard, one of the product managers on Flow, put together an excellent chronological list of all of the Flow sessions here. As you can see, there are 39 sessions that mention Flow or Next Best Action, which I think is more than double what we had last year. All of us here on the product team will be doing sessions, but there’s a huge wealth of sessions from familiar faces and new faces.

I’ll highlight some of the sessions being given by the product team, but I encourage anyone who is running a session to publish their own spotlight on what’s coming.

Tuesday

If You Want the Big Picture

VP Product for all things Automation John Kucera kicks things off first thing Tuesday morning with an authoritative, high-level, overview of the Salesforce Automation landscape. This will nicely set the tone for the week’s automation messages.

The Future of Automation on the Customer 360 Platform

Tuesday, November 19, 8:30 AM – 9:10 AM Moscone West, Room 2006

If You’re Looking To Make a Business Case

My colleague Jason Teller will follow John later Tuesday with a session strong on measurable returns and employee enablement. You will leave with an actionable pattern that you can use to build your own compelling Flow business case.

Agility and Innovation: The Business Case for Automation and Flow
12:30-1:10 | Moscone West, Room 2022

If You’re an Apex Coder

Product Manager Tim Peng and Chris Peterson will co-host this exploration of the strengths and use cases for Apex vs. Flow

Flow and Apex Showdown!
4:30-4:50 | Moscone West, Developer Theatre

Wednesday

If You’re Looking to Meet Shannon Hale, Live

Shannon Hale, the product manager with her own theme chant (do I sound jealous? I’m not jealous…much), will be providing a focused look at productivity wins you can achieve with multi-screen flows. I can’t reveal everything she’s preparing, but I can say that there’s a lot of chortling coming from the direction of where she sits.

Increase Productivity with Screen Flows
8:30-8:50 | Moscone West, Admin Theater

If You’re Looking for the High-Velocity Power Admin Experience

I’ll be running an admin-centric, high-intensity session, similar to the one I did at TrailheaDX, but with 100% new content. This is a popular session, but if your skull has any structural imperfections, you might want to stay away, due to the large amount of mind-blowing content that will be pipelined in your direction during this session.

Advanced Flow for Admins: Become A Salesforce Developer Using Points And Clicks
10:30-11:10 | Moscone West, Room 2002

If You’re Interested in Installable Solutions

Product Manager Sam Reynard will be running a session on templates, AppExchange, and more

Advanced Flow for Admins: Become A Salesforce Developer Using Points And Clicks
10:30-11:10 | Moscone West, Room 2002

If You’re Not Satisfied Short of Actual Salesforce Flow Engineer Employee Badassery

Nate Lipke, a longtime engineer on the Flow team here at Salesforce, is taking a break from some insane scalability enhancements he’s building into the Flow engine to give a focused session on flow scalability. This is the session we product managers will all attend but try to look like they actually know it already.

Designing High Performance Flows
5:30-5:50 | Moscone West, Architect Theater

Thursday

If You Want The Ultimate Drill-down on Flow Templates

Jason Teller and Flow expert Phil Weinmeister will focus in on templates and all of the ways they can eliminate Blank Canvas Anxiety

Prebuilt Business Processes with Flow Templates
1:00-1:40 | Moscone West, Room 2024

Friday

If You Want the Latest in Flow-based Enterprise Development

I’m very pleased to finally have a full dev-track session to focus on flow-development. This session will be heavy with useful patterns and will be the first place we preview some new 2020 flow functionality. I’ll be introducing some brand new patterns that make it easy to delegate management, configuration and even administration down out of Setup to other parts of the organization. There will be some strong material on Invocable Actions, integrating Next Best Action decisioning into Flow, and taking advantage of the new Flow ability to access Apex data structures directly and declaratively.

Developing Modern Enterprise Apps with Flow and Next Best Action
11:00-11:40 | Moscone West, Room 2009

When a record is submitted into an approval process, it gets locked. Sometimes it’s desirable to unlock the record manually.

In Salesforce Classic, you do that via a button that shows up here:

This button is not currently available in Lightning Experience, but it’s easy to add a quick action button to a record page layout that unlocks locked records.

The quick action button will run the following Unlock Record flow, which includes two new Flow Actions: Unlock Record and Get Record Lock Status.

Get Record Lock status returns a boolean value that tells whether a provided record is locked. Unlock Record unlocks it.

Installation

Before Installing

Besides installing the package below, it’s very important to make sure this setting is turned on:

Installation

Install Unmanaged 1.0.0.1

For Developers

View Source Code

Old Versions

Install Unmanaged 1.0

It can be tricky to get the right combination of defaults, initialization, and remembered values when users start clicking Next and Previous in a flow that has lightning components. Here’s some background and some guidelines to get the results you want.

Types of Mapping

Mapping is the process where the outputs from an ‘upstream’ Flow element are passed to the inputs of a ‘downstream’ Flow element. Mapping is the crucial glue that makes Flow so powerful. It allows you to factor time into your process (‘first do X, then do Y with the results of X’).

There have traditionally been two ways that information gets mapped between elements in Flow. “Standard” Screen components used Automatic Mapping and everything else, including Get Records, Flow Actions, and Lightning Flow Screen Components use Manual Mapping. (If you’re finding it confusing to have to distinguish between Traditional screen components and Lightning flow screen components, you’re not alone. To learn more about the difference between types of screen components, see this.)

Manual Mapping requires the flow creator to define and make use of temporary storage resources called Variables. We wanted to eliminate that requirement as part of an initiative to make flows easier to build, and so began in Winter ’20 to enable those parts of Flow that have required Manual Mapping to also be able to choose Automatic Mapping (We’re not going to try and convert existing Flows, and it will remain possible to choose either mode for all entities that previously allowed Manual Mapping).

Depending on the type of entity you’re working with, there are three combinations of Mapping modes that are available to you:

1) Mapping type: ‘Always Automatic’

Standard (or “Traditional”) field components in screens are always mapped in an automatic way. This means that you 1) add a Traditional field to an upstream screen, like this:

….and then in the downstream element where you want to use that value, you’ll find that it’s automatically available in the field picker in the Screen Components section:

There is no way to use Manual Mapping with a Traditional screen component.

2) “Manual ONLY” Mapping

When you use Manual Mapping, you manually create a Variable resource to hold your data, and then you use that variable first in the upstream element, where you deposit data into it, and then in one or more downstream elements, where you provide it as an input.

Manual Mapping is discussed in these tutorial videos. When manually mapping, you first create the variable using the New Resource button in the Manger:

Then you select the variable in the Output section of the specified entities. Manual Mapping was the only way to assign values before Summer ’19 for Actions, Aura flow screen components, Get Records, Subflows, and a sprinkling of miscellaneous mappings like Loop Iterator and Create Record Id. In Winter ‘20, Get Records and LWC flow screen components gained the ability to use Manual or Automatic mode and in Spring ’20, Actions also gained that ability. Finally, we added support for Automatic mode to Subflow and made the Loop element iterator automatic as well in Summer ’20.

3) Configurable Manual or Automatic Mapping

Here’s what configurable mapping looks like.

To the left, the checkbox is unchecked, and Automatic Mapping is in effect.
To the right, Manual Mapping has been selected.

Once a Flow entity supports configurable mapping, it will behave as follows: Existing flows with elements that have at least one manual mapping configured will open those elements in Manual mode. New flows will open all elements in Automatic mode except for Lightning Screen Components which default to Manual Mode in Spring ’20 but will start defaulting to Automatic mode in Summer ’20. Switching between the modes is allowed, but can be dangerous because you might break things downstream that rely on the old mapping.

How ‘Previous’ and ‘Next’ Affect Variable Values

Standard (“Traditional”) Components

Activity	Behavior
You 1) provide a default value, 2) make a change to the value of the field, and then later 3) return to the screen	The default value is only used the first time you go to the screen. Your changed value will be remembered

Standard fields emphasize remembering the last value the user provided. You can go back and forward, changing the value if you want, and each time you return to this display screen, it will show your latest value.

Components that Have Inputs and Outputs
Flow screen components, actions, and subflows expose for each attribute an input field and an output field. If you want to set the default value of an attribute, you map an upstream value into the input field of that attribute. What happens next depends on the entity. If it’s a subflow or an action, it will go off and do some processing, and return a set of values which are made available to anything in the output field (or to any reference to the output attribute generated by Automatic Mapping.) Note that in these cases, there’s no opportunity for the user to interact with that process. For screen components, it’s a little more complicated, because the user can potentially modify the values of the attributes if the component is designed to allow it.


“Remember” vs. “Reset”

Consider the following case:

1) User starts by entering a value “FirstString” in Screen 1.
2) User clicks next, and that value is mapped into an attribute of the screen component and displayed there.
3) Clicking next again leads to a screen with a Display Text field that is mapped to the output of the Screen 2 field.
4) User clicks previous, back to screen 2. User sees as expected the output that user typed in screen 1.
So far, so good. But the user wants to change the value that the screen component is displaying and the only way to input a value is to go back to screen 1. So…
2) User clicks previous AGAIN, back to screen 1, and types a new value, called “2ndString”.
3) User clicks next, going forward and returning to screen 2.

Stop for a moment and ask yourself what you expect the component in screen 2 to now display.

A lot of people will expect it to say “2ndString”, but it will actually display the original value, “FirstString”.

Why is this?

The first thing to note is that Traditional fields like Text behave the same way! In this video you can see that when we return to screen 2, it doesn’t update to reflect the new value typed in screen 1. It’s easier to understand with text fields than it is with lightning components because the inputs for the text fields are clearly labelled “Default Value”. Text fields in flow are optimized for a case where the value my need to be initialized to a default value, but once the user enters something else, the text field should not be reset.

Understanding ‘Remember’ Mode
Let’s return our attention to Lightning Components in Flow Screens. Lightning Components behave the way described above if they are configured in what we’ll refer to as Remember mode. This mode is entered if a Lightning Component has values mapped for both the input and the output of a particular field or is using Automatic Output Handling. In this mode, the component behaves like the Traditional text field in the video above, treat inputs from previous screens as defaults and remembering the original value the user provided the first time through.

The use case for Remember mode is where the user types lots of values into fields of a component, goes back to check on an earlier value on and earlier screen, and then returns to the first screen. They don’t want to have to type everything in again.

One common use case for having values mapped for both the input and the output of a particular field is when you want to be able to click previous from downstream in the flow, return to a screen with a lightning component, and have the component reload the value that it output the first time. To do this, you have to use the same variable or reference in both the input and output fields. This is described int the ‘Tip’ section on document pages like this one. But whether the mappings are the same or not, the component will be in Remember mode.

This doesn’t always result in logical behavior, unfortunately. Suppose you click previous again, and go upstream back to screen 1 and change a value, and then click next to slide downstream back to your screen 2 lightning component. Because the component is configured in Remember mode, it will act as if it was saying “I’m not accepting any more default values. The user provided a value the last time they were here and I remember what it was”. And so it will refuse to update to the value the user has just typed into the upstream screen.

Understanding ‘Reset’ Mode
If a Lightning Component has only one of the input and output values mapped for an attribute, it will reset that attribute each time the screen loads. This will cause any value from a previous screen to be used. Since Automatic Output Handling automatically maps all output attributes ‘under the hood’, a field on the component that has an input mapped to it cannot be in Reset Mode if Automatic Output Handling is activated (the “Manually assign Variables (advanced)” checkbox is unchecked), because it triggers the “both fields are mapped” rule discussed above.

How Automatic Output Handling Affects Mode
In Winter ’20, Flow started adding Automatic Output Handling. Features that support Automatic Output Handling in Winter ‘20 include Lightning Components. When you newly add an LC to a flow screen, automatic output handling will be on by default. This is represented by the “Manually assign Variables (advanced)” checkbox always being unchecked for new flows and new screens.

This new feature promises to greatly simplify the creation of flows because for most use cases, it completely eliminates the need to even know what a variable is. However, its use has an important ramification: when you use Automatic Output Handling on a lightning component in a flow screen by leaving the “Manually assign variables (advanced)” checkbox unchecked, every attribute of the component will act as described above in the “remember” scenario, treating subsequent inputs from upstream as default values that should be ignored.

Workarounds and Roadmap

We know that there are some customers who have flows where the current behaviors are not desirable. There are several potential workarounds available today. In addition we plan to provide additional control capabilities in the future.

If you want users to be able to return to an upstream screen, enter new values and have those values properly updated into your lightning component, you can use the following approaches:

DISPLAY-ONLY

I have a “Display-Only“ component so I don’t need to use any values from the lightning component downstream
Some components are intended for display only and don’t take inputs from users. In this case, you can avoid Remember mode by making sure that:
1) if you are already in Manual mode (i. e. the Manually assign variables (advanced) checkbox is unchecked) for the screen that contains your component, just make sure that you have not mapped a variable in the Output section for the attribute that you want to reset
2) if you are in Automatic mode (the checkbox is unchecked), turn on manual mode, and make sure to leave the Output field corresponding to the attribute that you want to reset empty.

ALWAYS RESET

I have a screen component that doesn’t use any values from upstream. The values are always entered directly via my component’s UI, and I will use some of those values downstream, and I’m ok if the user has to re-enter values into my component if they go downstream and then click previous and come back to it.

This is basically the scenario where you might map a value to the attribute’s Output but leave the attribute’s Input empty. As described above, if the Input and the Output for an attribute both have values, Flow will use ‘remember’ mode. That’s not the case here, so Flow will reset the lightning component. That means that if the user fills out fields in the component, clicks next and then clicks previous, all of the fields will be erased and the user will have to reenter the values. In most cases, this is undesirable and in fact preventing this need to reenter values is one of the reasons ‘remember’ mode exists. But if you can’t do the best solution (see below) then this may be the best of the two remaining workarounds. Similar to the Display-Only solution, you need to click on Manually assign variables (advanced) to take advantage of the ability to use reset mode. Then you leave the Input empty and use the Output.

USE DIFFERENT ATTRIBUTES FOR INPUT AND OUTPUT (Best Option)

I want to remember everything that gets entered both upstream and downstream, and I’m able to make code changes to the component in question
All of these forced tradeoffs ultimately trace to the fact that we’re trying to get a single lightning component attribute to do too many things at the same time. The cleanest way to maintain maximum control is to split the problem attributes into two. For example, suppose you have a lightning component with an attribute called ‘value’. You want value to always update when the user goes back upstream and then returns, and you want value to always remember and reload values if the user goes downstream and then comes back.

To solve this, use two attributes instead of 1. We’ll call the first one ‘intakeValue’ and the second one ‘outflowValue’ in your lightning code. Turn on Manually assign variables (advanced), and map your screen 1 text input to the input of intakeValue and use intakeValue within your lightning component, but make sure that you leave the “Output” of intakeValue blank so that it stays in reset mode. Every time the value of intakeValue changes, detect it with a change handler and copy it to outflowValue. Meanwhile, for outflowValue, we want to be in ‘remember’ mode, so we either want to leave ‘Manually assign variables (advanced)“ unchecked or, if it’s checked, make sure that variables or references are mapped to both the input and output of outflowValue. This latter choice has an artificial feel to it, though, because we don’t actually intend or want to actually pass data into outflowValue from upstream in the flow. We only want to copy the value of intakeValue over (and update it with any additional processing that happens inside the LC. So using Manually assign variables(advanced)” for this outflowValue is not recommended.

To summarize:

Attribute	Purpose	Check “Manually assign Variables”?	Map something from upstream into the ‘input’ of this attribute?	Map something from downstream into the ‘input’ of this attribute?	Map something from downstream into the ‘output’ of this attribute?
intakeValue	receives values from upstream in the Flow	Yes	Yes, to provide defaults or updates from earlier screens	No	No
outflowValue	provides values to the Flow downstream	No	Not applicable	Not applicable	Not applicable

Don’t forget to internally copy all changes to intakeValue over to outflowValue!

What about the recommended practice of achieving remembrance by mapping the same variable to both the input and the output of a variable? That will continue to work fine for existing flows, which will always automatically turn on Manually assign variables (advanced)“, but for new flows, we recommend leaving the box unchecked, as it will provide remembrance automatically.

Roadmap

For Spring ’21 we’re looking at ways to address the issues discussed here.