Apart from Record Triggered Flows for Fast Field Update, you can use subflows in almost any type of flow. Utilizing subflows in them has many benefits.
Subflows can be used again and again
One of the key advantages of subflows is the ability to reuse sections of logic in multiple Flows. By creating a subflow, you can isolate a specific subprocess and incorporate it into different Flows. This eliminates the need to maintain the same steps in multiple flows when changes are required. You can use the same subprocess with different record triggers, in Scheduled Flows, and even in an Action to execute the flow manually.
If you want to execute a specific autolaunched flow via an Action, build a Screen Flow with an input variable named recordId
. It does not need to be a text variable containing the record's ID; it can also be a record variable.
Next, place the subflow as the only element in the screen flow and pass the recordId
to the appropriate input variable of your subflow.
In the Object Manager, you can now create an Action for your Screen Flow.
Improved Readability of Flows
When you have a large flow that consists of many subprocesses, it helps to enhance the flow's readability by separating the subprocesses that can work independently from the rest (except for their input variables). This is also a common practice when outlining the process for documentation purposes.
Let's take the example of creating a Work Order.
- The customer needs to be selected
- A contact needs to be chosen from the Contacts of that customer, with an option to add a new contact person at that time
- The asset(s) requiring maintenance must be selected
- The parts to be used and the steps to be performed must be determined
The main flow can include these steps in the form of a subflow for each subprocess. This way, you can quickly zoom in on the relevant part of a large process because you can see at a glance where the section you want to focus on is located.
Easier Testing of Autolaunched Flows
If your logic is directly embedded in a Record Triggered Flow, you can only test and debug the flow by simulating a specific record change. Finding the field you want to modify can take some time, and sometimes the field in question may not even be visible or editable. This is why it's better to separate them. By building your actual process logic in an Autolaunched Flow, you can test the process independently and quickly identify whether any potential issue lies in the executed steps or the trigger.
If your logic is directly embedded in a Scheduled Flow, you cannot choose the record with which you debug the logic in the flow. You can schedule the flow to run exactly in the next minute and activate it, but it is simply easier to have the logic within a subflow and test it as and when you wish.
In both cases, you can test the logic independently of the trigger (the event that initiates a Flow Interview). Once you have perfected the subflow and test the Record Triggered Flow or Scheduled Flow with the subflow embedded in it, you know that if any errors occur, you need to investigate the outer flow. The Entry Criteria are usually the most logical place to start investigating.
Conslusion
By leveraging subflows, you can enhance the reusability, readability, and testability of Flows in Salesforce, leading to more efficient development and maintenance processes.