I have several LWCs linked in a flow where each flow element is configured like this to share the current state of a Contact record:

image of config


  • "Manually assign variables" is checked
  • "Refresh inputs to incorporate changes elsewhere in the flow" is chosen

Each LWC includes this console logging:

    _contact = {};
    get contact() {
        console.log('RegistrationType get contact ' + JSON.stringify(this._contact));
        return this._contact;
    set contact(c) { 
        console.log('RegistrationType set contact ' + JSON.stringify(c));
        this._contact = c ? { ...c } : {}; 

But when going back to the first element that uses the RegistrationType LWC from the second element that uses the RegistrationDetails LWC, the debug output is:

RegistrationDetails get contact {"Email":"[email protected]","FirstName":"K","RecordTypeId":"0120x000002eG3jAAE","LastName":"C"}

RegistrationType set contact {"RecordTypeId":"0120x000002eG3jAAE"}

i.e. a stale value is set on the first element rather than the desired value from the second element.

There is no database interaction here: the aim is to use the flow variables to hold the state until a final "commit" element.

(There is a similar but unanswered question here Background: Screen Flow Revisited Screen Values)

What am I missing here?

2 Answers 2


This is working as designed from what I understand, unfortunately. That feature (refresh inputs) applies only to when making edits to previous pages and then revisiting subsequent elements that leverage those values. When it was added in Spring '21, you'll notice the language it used:

When a user navigates to a previous screen, then proceeds forward to a screen that they visited already, the flow can refresh screen component values.

And Salesforce Scheduler, when they leveraged this feature in their standard flows, only highlight the ability to make changes on previous pages:

Configure your Salesforce Scheduler flows to ensure that when users go back to a page and make changes during appointment scheduling, the changes are reflected on the subsequent pages.

Your use case, where you want refreshed values when you navigate backwards to a previous screen, is not part of this feature.

The scenario this setting applies to is the following:

  1. Update Contact in Screen 1
  2. Go to Screen 2 and it displays what was in Screen 1
  3. Hit previous & re-edit values in Screen 1
  4. When you navigate forward again to Screen 2, it'll have refreshed values

For your scenario, you're hoping it'll refresh going backwards - but, it'll be in "remember" mode which is what you're noticing (the value it had the last time it visited)

So what are your options?

It might not be scalable depending on the complexity of your flow and # of elements - but, you can ensure your flow is always moving forward - even when the user thinks they're going backwards.

This would require you to hide the default standard Flow navigation buttons and handle it in your LWC. When they click your "previous" button - you move them forward but set some Boolean output variable that a decision node can leverage to loop to the previous screen element.

    this.goBack = false;
    const navigateNextEvent = new FlowNavigationNextEvent();

    this.goBack = true; //output flow variable used in next decision element
    const navigateNextEvent = new FlowNavigationNextEvent();

enter image description here

  • Thanks Kris, and thanks for the work-around option. I had the impression that values were propagated when going "back" later on, but may be wrong about that.
    – Keith C
    Commented Apr 30, 2022 at 16:24

I have Found Work around

After you are done with using screen components somewhere in Flow Before revisiting same screen use assignment Operator & set Field value NULL or Blank for that fields.

This Should definetly work. I have tried with Object record fields as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .