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:
i.e.:
- "Manually assign variables" is checked
- "Refresh inputs to incorporate changes elsewhere in the flow" is chosen
Each LWC includes this console logging:
_contact = {};
@api
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?
Best Answer
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:And Salesforce Scheduler, when they leveraged this feature in their standard flows, only highlight the ability to make changes on previous 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:
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.