Optimizing Lightning Component Inputs and Outputs in Flow Screens

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. “Native” Screen fields 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 Native screen fields and flow screen components, you’re not alone. To learn more about the difference between types of screen fields and 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’

Native field components in screens are always mapped in an automatic way. This means that you 1) add a native 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 screen field.

2) Mapping Type: Manual ONLY

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 required before 222 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 will also gain that ability, with the remaining holdouts gaining that ability in 2020.

3) Mapping Mode: Manual or Automatic

Here’s what Manual or Automatic 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 is converted to use this mode, it will behave as follows: Existing flows that have at least one manual mapping configured will open in Manual mode. New flows will open in Automatic mode. Switching between the modes is allowed, but is dangerous because you might break things downstream.

How ‘Previous’ and ‘Next’ Affect Variable Values

Basic Fields Are Are Straightforward
Suppose you fill out a field with a value and click next. You can display the value you entered on the new screen. Here, we map the value to a Display Text element on the second screen.

You can go back and forward, changing the value if you want, and it will work fine. Each time you return to this display screen, it will show your latest value.

Things That Aren’t Basic Fields 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 will show that value in a Display Text field, regardless of whether user used a manual variable or an automatic output reference.
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 text fields 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
Back to Lightning Components. Lightning Components will behave this way is they are configured to Remember instead of to Reset. If a Lightning Component has values mapped for both the input and the output of a particular field or is using Automatic Output Handling, then it is designed to behave like the normal text field in the video above, treat inputs as defaults and remember the value that the user provided the first time through. You can also use this capability to reload lightning component when you click previous to return to their screen with a remembered value from downstream if you use the same variable or reference in both the input and output fields. But whether the mapping 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, it will reset each time the screen loads. This will cause any value from a previous screen to be used. Since Automatic Output Handling automatically maps all attributes ‘under the hood’, you cannot enter Reset Mode if the Manually assign Variables (advanced) checkbox is unchecked.

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 this combination of behaviors is 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 turn of 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 need to use some resulting 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
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:

AttributePurposeCheck “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?
intakeValuereceives values from upstream in the FlowYesYes, to provide defaults or updates from earlier screensNoNo
outflowValueprovides values to the Flow downstreamNoNot applicableNot applicableNot 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

We’re considering a couple of changes for the future:

1) Change the Base Behavior so Automatic Output Handling always uses Reset mode
This would replace the current rules with the following: “if different sources are mapped to the input and output for an attribute, then if you’re entering the screen as the result of a Previous, use the Output and if you’re entering the screen as the result of Next, use the Input. This would become the default behavior for Automatic Output Handling. The only combination that would result in Remember mode would be to 1) use Manual Mapping and 2)map the same variable or reference to both the input and output of your attribute.

2) Add a manual toggle to all fields capable of using both modes.
It would look something like this:

When returning to this screen:
( ) Always reset this field to the latest value
( ) Always remember the first value provided.

We’re interested in feedback on this topic.

1 reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply