5 Times You Should Use a Subflow in Salesforce

I recently gave a presentation at Midwest Dreamin on Flow FUNdamentals, and an attendee had a good question that I don’t think she was the only person to wonder about: when is the right time to use a Subflow in Salesforce? Subflows are a very powerful tool, and there are a few key use cases where they can provide a lot of value to your Salesforce organization.

1. Simplify Complex Automations

Sometimes, you need automations that do a lot of heavy lifting. Maybe when you create an Opportunity, you need to Salesforce add certain Contacts associated with Accounts that meet certain criteria as Contact Roles, set the Opportunity’s Pricebook based on the Account billing address, and add certain Users to the Opportunity Team based on certain attributes of the Account. You could put all of this logic in a single flow. If you did, it would look something like this:

Example of complex automations in a single flow

Such big flows can become unwieldy, challenging to maintain, and difficult for new admins to understand. Instead, we can break this functionality into separate subflows.

First, we can break out the logic for creating the Opportunity Contacts. Because we will want to pass in different groups of Contacts and, in other instances, not create any Opportunity Contacts, we can leave that logic in the Create Opportunity flow. In the subflow, we can pass in the Contact Collection variable and the Opportunity ID as input variables.

The subflow will look something like this:

Subflow passing in the Contact Collection variable and the Opportunity ID as input variables

Next, we’ll make a subflow to create the Opportunity Team Members. Because we will always be creating our Opportunity Team, we can create an Opportunity record input variable in this subflow and have all the logic for finding the right group of Users and creating Opportunity Team Members included in the subflow. It will look something like this:

Subflow to create the Oppotunity Team Members

Setting the Pricebook is simple enough that it probably doesn’t need a subflow. With these two subflows, now our Create Opportunity record-triggered flow will be a lot easier to understand:

Create Oppotunity record-triggerd flow

We’ll get the collection of Contacts we need, then pass the Opportunity ID and the Contacts into our Create Opportunity Contacts subflow (or bypass the subflow if we go down the Add No Contacts path). Then, we’ll get the Pricebook we need and set the Opportunity’s Pricebook value. Lastly, we’ll create all the Opportunity Team Members we need.

How big or complex does a Flow need to be to break it into subflows?

It’s really more of an art than a science. Breaking flows into subflows can make debugging the flows a little bit more challenging, especially when a flow requires you to pass in collections as input variables. It also depends on how many users will be accessing the flows: teams with more admins should be more rigorous about creating subflows, as there’s a higher likelihood that someone unfamiliar with the flow will need to access or modify automations at some point in the future, so it’s important that automations be easy to understand.

A general rule of thumb is: if there are distinct steps that involve more than a simple Get and Create/Update element and represent a discrete process, it might be a good candidate for a subflow.

2. Centralize Same or Similar Processes That Fire from Different Sources

Let’s say that your organization has complex logic to set your Case Due Dates. For new Cases, we want a flow to set the Case Due Date to be due the first business day (meaning it can’t be due on a weekend or holiday) 1 month from the date the case is received, among other fields, such as Case Origin.

However, if your support agents request an extension and get it approved, we want a flow to set the Case Due Date due to the first business day three months after the date the extension is granted (meaning, again, it can’t be due on a weekend or holiday) as well as other fields, such as Case Status.

Calculating Due Dates with Subflows

In both cases, based on a certain date and number of months, we’ll need to calculate the due date. To do this, we’ll want to create a subflow that has two input variables: InitialDate and NumberOfMonths.

The subflow will also have an output variable: DueDate. You can build the logic to calculate the date in the subflow.

Now, in your Case Create flow, you can call your Due Date Calculator subflow, inputting a formula DATEVALUE(Record > CreatedDate) as InitialDate and 1 as NumberOfMonths, and in your Update Case element, set Record > Due Date to Outputs from Due Date Calculator > Due Date.

Similarly, on your Case Extension Approved flow, you can again call your Due Date Calculator subflow, this time inputting Record > Date Extension Approved as InitialDate and 3 as NumberOfMonths, and in your Update Case element, set the Record > Due Date to Outputs from Due Date Calculator > Due Date.

Centralizing this logic in the subflow is beneficial from a maintainability standpoint, too!  Should the logic for calculating the due date ever change, you will only need to make the update in the Calculate Due Date subflow. It will be applied in all places where that subflow is called rather than needing to implement the same logic across multiple flows.

3. Initiate Automation from Apex Code or REST API Calls

The technical name for a subflow is an autolaunched flow. This type of flow is extremely powerful because it can not only be invoked by flows but can also be called from apex code or even API calls.

This means that if you have a developer who is doing some process but is stretched for time, you can collaborate with them to have their apex code call a subflow that you have made. Then, pass in whatever data you need as input variables and execute the actions you need in a flow, thus taking work off of the developer’s plate.

Similarly, if Salesforce has a custom integration with another system and the two systems’ data schemas don’t quite match, that system can call an autolaunched flow and send in the data inputs. You can use the flow to transform the data into the structure needed in Salesforce.

4. Run in Different Contexts to Access Data

Salesforce has a complex data access model that ensures that only users with the right permissions can view or modify sensitive data. However, there are rare instances when the actions taken by a user who normally doesn’t have permission to edit a record should result in a record being updated.

Let’s say that normally, a Sales Rep shouldn’t be able to edit Cases records at all. However, if a Sales Rep sells an Account a premium-tier support license, all open Cases should automatically be escalated. In such an instance, you could create an Escalate Case subflow and set the subflow’s How to Run the Flow to “System Context Without Sharing—Access All Date” (this is done by clicking the flow’s gear icon and expanding the Advanced Options). Then, call that subflow from the Account Edit flow (which runs in the “System Context with Sharing—Enforces Record-Level Access”) that fires when the Account Support Level is changed to Premium.

Creating an Escalate Case subflow

This ensures that the right records get modified without needing to make fundamental changes to your data-sharing settings.

5. Tracking Failures

Users don’t always get notified when flows fail. For example, if a user triggers a flow that has a scheduled path and an element on the scheduled path fails because it hits a validation rule, the user will be none the wiser. Likewise, when subflows fail, Salesforce doesn’t let you display custom error messages.

Accordingly, it can be useful to create an Error Message subflow. This subflow would have several key input variables: FlowName, RecordId, and PointOfFailure. The subflow can then have an email action that goes to the system admin, informing them that the flow has failed, the record it failed for, and the name of the element where the failure occurred. This will help surface failures and help the admin troubleshoot.

Working with an Experienced Salesforce Partner

Flows are an amazingly powerful tool for automation. Subflows can make your Salesforce organization more efficient and maintainable while allowing you to expand the functionality of your developers’ work and custom integrations. If you need help getting the most out of Salesforce, our team of experienced professionals can help. Contact us to talk with a consultant today.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top