Screenflows, you know them, components too, but would you like more interactions in all of this? Would you like your components to be able to influence the screenflow or other components within this flow?

 

Don’t scroll, you’re in the right place, I’ll explain it to you.

 

Explanation by Example

Let me take as an example a screen flow in which I would like two custom selection lists each having the following instructions:

• Take as input a variable to filter the selectable contacts that I will name “filtersearch“.
• Provide as output a variable that can be used as a filter for a second instance of this same component that I will name “outputfilter“.
• Provide as output a variable with the value (ID) of the selected contact simply named “value“.

 

1/ The Lightning Component

a – Component Configuration (.js-meta.xml)

In order for the input and output variables to be visible in the screenflow, they must first be declared in the component.

I must therefore define “lightning__FlowScreen” as the “target” and its associated configuration to expose the “filtersearch“, “outputfilter” and “value” variables.

 

 

Here, on the “lightning__FlowScreen” “targetConfig“, for each property, I can use the “role” attribute to make the variables visible only in input or output.

 

b – Component Code (.js)

For the component to be able to notify the screenflow that a variable has been modified, I must first import the “FlowAttributeChangeEvent” event.

It is not necessary to install a third-party package, since this event is an integral part of the Salesforce lightning web components.

 

 

For input variables, it is also very simple, since it is enough to declare them with the “api” annotation.

 

 

My code editor (here VSCode) automatically offered to insert the appropriate “api” import.

 

 

In this article, I will not go into the full details of the component, but to keep it simple, I will take the input variable “filtersearch” and, if it is not empty or null, use it as a WHERE condition in a SOQL performed by the component (via an Apex class) to list the contacts different from the one already selected by another instance of the component. The format of the “filtersearch” and “outputfilter” variables must therefore be of the form “Id <> ‘randomID‘“.

The modification of the “filtersearch” variable must therefore trigger a new query to update the selection list of the component.

Similarly, any change of selection must provide as output the updated “outputfilter” and “value” variables and inform the screenflow so that the latter takes them into account.

I will therefore skip the first part concerning “filtersearch“, as this is not the main subject of this article, in order to concentrate on the constitution of the updated value as well as on its notification to the Screenflow, in order to allow the component to propagate these values to my flow as well as to the other instances of the component that are integrated into it.

I therefore create a JS function that will be called on the onclick/onchange event of the html list component which is responsible for informing the flow of the value changes of the variables.

 

 

I do not detail here the apex class used by the component to generate and execute the SOQL with potentially the filter on the value of “filtersearch” (because yes, it is also necessary to consider the case of the component which does not take the value of “filtersearch” into account.

I will just for the rest of the article consider that my component is named intf_CustomLookupInputField.

 

2/ The Screen Flow

Now that my component is created and deployed in my org, I create a screenflow. In my screen, I will be able to integrate it twice.

Lightning components are in the list of components under the custom category.

In my screenshot below, I used the component twice as an example. The first component does not receive any input parameters, which allows it to display all the contacts I have access to. On the other hand, for the second component, I entered the output value of the first component in “filtersearch”, so that the second list displays all visible contacts, except for the one selected in the first list (first instance of the component).

 

The Salesforce flow editor simplifies the task by directly offering me the screen components that I used in my screen, as well as the available output variables.

 

 

In the following steps of the flow (at the exit of the screen), it is also very easy to retrieve the value (via the “value” attribute of the screen components) selected in each of my lightning components in order to assign them to a record or use them in conditions for example.

 

All that remains is to save and test the component in the screenflow which behaves as follows:

• I select a contact in my first list.
• My component notifies the flow that the “value” variable has been modified.
• My component notifies the flow that the “outputfilter” variable has been modified.
• The flow automatically transmits (propagates) this change to my second component in the “filtersearch” variable.
• My second component triggers the refresh of the list options.
• My second component no longer offers me the contact selected in the first component.

 

In these screenshots, in the Name list, I chose Rose, and I can see that in my second list this contact is no longer available.

 

 

Mission accomplished then. Of course, it is possible to go much further and this opens the way to components not only very useful, but reusable at will and configurable by our functional consultant friends.

 

I also invite you to consult the Salesforce documentation about the support of flows in LWCs.