|
|
About the Author:Jonathan Davis is a Salesforce Consultant at Venn Technology in Grapevine, TX. He enjoys the challenge of mastering all things Salesforce. With seven certifications under his belt and counting, he’s always tackling Salesforce Trailhead to up his integration and configuration skills. |
In our previous articles, we have covered the Assignment, Decision, and Data elements, talked about the flow resources inside of flow with Variables, Collections, and Formulas, and discussed the Loop, Collection Filter, and Collection Sort elements for working with large numbers of records.
In this article we will be covering the remaining set of flow elements: Screen, Pause, Action, and Subflow. These elements provide flow builders with the tools to collect information from the user mid flow, pause the flow until a later time, and launch a variety of actions and other flows.
• Screen
• Pause
• Action
• Subflow
• Tips and Tricks
The Screen element is unique to screen flows, and provides a way to display and collect information during the flow, allowing users to input data and control the path of the flow’s logic.
Within the screen element, the header and footer settings are configured, and components are dragged from the side menu and organized on the screen as needed. The three categories of components are Input (which collect user input), Display (which organize and display values), and Custom (which can be developed and installed to do a variety of things).
All screen components other than the section component (which is used to structure other components) require you to set their name and API names, and the input components can then be referenced as variables later on in the flow to access the values input by the flow user.
The various input components have a number of fields that can be configured to set a variety of qualities for that component. For example, many input components also accept default values that are displayed in the component when the user first sees it. Many input components can also be marked as required, forcing the user to input a value in order to proceed in the flow.
In the example below, the Email component can be marked as Required by setting the field to true or false, and a default value can be set in the Value field. The email field also has a Placeholder Text field to display an example of what a valid value would look like to assist users in filling out the form.
Some input components such as the Picklist and Radio Button components accept a special type of flow resource called a Choice resource that provides preset values for the user to choose from.
Choice resources have 4 types:
The Lookup component uniquely allows you to replicate an existing Lookup field in your Salesforce Org for use in the Flow. When configuring the Lookup component, you set the API name of the component, the API name of the field you want to reference, the label you want to display for the user on the screen, the API name of the Object the Lookup field is on, and can optionally set the default record for the component to display when the screen loads.
Below, we access the AccountId lookup field on the Opportunity object:
Some components such as the Text component also allow their input to be validated by defining an error message and formula to trigger the error. Flow resources can be referenced within the validation formula, allowing for fine grained control over what values are allowed in various situations.
Note that unlike validation rules elsewhere in Salesforce, these validation formulas trigger the error when they evaluate to false rather than true.
Below, we require any text entered into the test field to contain the value “TEST” by having the component reference itself within the CONTAINS() function.
All screen flow components can also have their visibility set based on customized logic. This logic can be based on values set previously in the flow as well as the result of selections or inputs on other components on the same screen.
This allows you to only show the fields that are relevant to your user and help to consolidate the number of flow elements used by allowing a single screen element to hold the input and display values for a number of situations.
In this example, we only show the address section if the “Also update Address on File” box is checked.
The Pause element can only be used in autolaunched flows and scheduled flows, and flows including a pause element cannot be called by record triggered flows or screen flows.
Like the name suggests, the Pause element pauses a flow until a specified time or event before allowing the flow to continue. The flow transaction that started the flow ends when the flow is paused, and a new transaction is created when the flow resumes. This allows Pause elements to avoid hitting flow limits by pausing the flow when it might be close to hitting a limit and then resuming with new limits.
The Pause element can have a number of configurations set when it is added to the flow. Each configuration can be set to either always run or have a set of pause conditions similar to a Decision element, and has a resume event that tells the flow when to resume. The resume can either be a specific time after the pause, or when a specific Platform Event is received.
The Action element allows for standard or custom actions to be launched from the flow for a variety of uses.
Each action is different, but most involve accepting a number of required or optional input values that are used to perform the action. These values are typically either text values entered within the Action Element, or referenced variables set previously in the flow.
In the below example, the Send Email action is used to send up an email using a Text Template variable for the body, a text variable for the Subject, a text collection variable to store the list of recipient emails, and allowing the email body to contain Rich Text.
Salesforce includes a number of standard actions such as the “Send Email” action, and more actions can be developed or installed.
The Subflow element is used to trigger an autolaunched flow within the same transaction as the original flow.
Subflows are a great way to reuse flow functionality without having to create the same or very similar flows more than once across your Salesforce Org, which can save time creating the automation and makes it much easier to manage going forward.
If, for example, you needed to trigger a complex flow to close an Opportunity and create some related records, but had a variety of ways you wanted to trigger the flow (such as automatically when the Opportunity reaches a certain stage, as well as at the end of a screenflow on the page layout specific opportunity record types), you can create the logic without a specific trigger in an Autolaunched flow and then use the Subflow element within other flows to call the logic when it is needed.
When the Subflow element is used to call another flow, any variables within the Autolaunched flow marked as “Available for input” will appear in the Subflow element to accept input from values for the flow to use.
The values input into the flow can be text typed into the Subflow element itself, or any variable from within the flow that matches the data type of the Autolaunched flow’s input variable.
Once the autolaunched flow from the Subflow element runs, the original flow continues. All variables from the Subflow that are marked as “Available for output” can then be referenced as resources by the original flow.
A convenient use of subflows is that they are not reliant on a specific object like many other flow types are. This means that you can configure the subflow to accept more generic values such as text or number variables and call it from any object that contains the needed values to perform a specific logic or calculation, and then return that to the original flow.
For example, if there is a complex calculator that needs to be triggered at various stages of the Lead, Opportunity, and Contract objects but the output relies on a State/Region text value and various currency values, a single autolaunched flow can be created with input variables for the State/Region and Currency values that can be called by flows from each other object.
Screen elements can be used in loops to allow the user to view, input, and make choices based on values in each item in a loop. This can allow users to review and act upon lists of records one at a time until each is resolved.
Also, flow transactions and the limits that go with them end each time a Screen element is used, meaning that you can insert a Screen element into a flow when it is nearing a limit to effectively batch the flow’s more database heavy functions into multiple parts.