Connecting flows and subflows
We can connect data between flows using input/output resources. When you set up a new resource, you can specify whether that resource can be seen from outside its flow, as shown in the following screenshot:
Setting our resource’s availability
Let’s say we want to create a flow to help sales reps create opportunities. The first step would be to get customer data and then use that data to compile the opportunity object. Our previous New Customer Info flow can be configured to have the contact and account resources set as input and output variables that can be accessed outside of the flow itself (so that they’re accessible from the other flows that are connected to it).
In the new New Opportunity flow, we start by gathering account details that are not used to identify the account (for example, the company’s website, or any other field that is not set to empty in the first assignment screen of the New Customer Info subflow) and that we actually want to store in the account record. To do this, we simply created a new screen element and a new tempAccount resource to store those fields.
By adding a new subflow, we are selecting the whole customer identification form without creating every element again, as shown in the following screenshot:
Subflow configuration
After selecting the New Customer Info flow, we can set up the input variables (in our scenario, this is only the account resource), along with two new resources for the output account and contact resources coming from the subflow:
Output Values definition for a subflow
This way, when the New Customer Info flow ends, we are able to take account and contact data and use it in our opportunity flow. We can even create a new flow for service management, which creates a case, and still use the New Customer Info flow to identify the customer.
Cool, huh? This may seem complicated at first sight, but hopefully, this section has proved otherwise.
Autolaunched flows
What if you don’t need a user interface but want to implement complex automated logic for your records?
This is where the autolaunched flow type comes into play. Here, we can define a Process Builder with a flow action to trigger the flow logic when a specific event occurs on an object type (for example, an opportunity is created).
The toolbox changes slightly for autolaunched flows:
Autolaunched flow toolbox
The Screen element disappears, while the Pause element is added to the Logic elements section.
This particular element, which can only be run on autolaunched flows, is used to put the logic in a waiting state until specific conditions are met.
It is composed of the following:
- One or more pause configurations: These define (pretty much like we’ve seen in the Decision element) different paused paths that can be resumed with specific configurations:
Pause configuration and conditions in the Pause element
- One or more resume events: These define the events that resume the flow for a given path; they can be based on a simple date/time value (fixed or resource-based) or on a platform event:
Resume event for a given pause configuration
Here is a quick example:
Example of an autolaunched flow with a Pause element