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.