When to use subflows…

Hey Everyone,

Happy Saturday!

Today we’re going to dive into using subflows in the Salesforce flow builder.

A subflow is an auto-launched flow that is used in the middle of a different flow.

Subflows allow you to create modular and reusable functionality.

You can pass variables into them and have variables output by them.

This allows you to build a subflow once and use it (and the output it produces) over and over again.

As an example, let’s say we work for a company – Universal Containers – that has an Account Role field on the Contact object.

Universal Containers uses Sales & Service Cloud and don’t have Person Accounts enabled.

The Account Role field denotes the role of the contact for that account, with one key value being “Primary Contact”.

Universal Containers wants to ensure new Salesforce records such as Opportunities, Cases, Tasks, and some Emails are related to the Contact who has an Account Role picklist value of “Primary Contact” for each Account.

Further, if there isn’t a Contact that meets the requirement, Universal Containers wants us to find the Oldest Contact by created date instead.

The logic might look something like this:

As a result of this ever-present requirement, many pieces of automation that we might build will require us to repeatedly create the same the same logic that looks up the Primary Contact.

And that approach makes building each flow a little longer.

Also, if Universal Containers ever changes the lookup logic we’ll have to update every flow we ever built this logic in.

For example, if a new picklist value “Secondary Contact” is added, and we are asked to add a lookup for Contacts meeting this criteria before we check for the oldest Contact by created date, we’ll have a ton of reconfiguration work to do.

Instead, we could build a subflow that accepts an AccountId as an input parameter, and returns a ContactId as an output parameter.

Then we can use this subflow in every other flow where we want to find the Primary or Oldest Contact.

We pass in the AccountId, and it returns the ContactId.

We can use the result of the subflow to set field values in any flow that we call the subflow in.

By setting up a subflow to give us the output we routinely need to find, we can easily find the Primary (or Oldest) Contact Id inside any flow (with minimal effort).

If the logic Universal Containers uses to find the Primary Contact ever changes, we can update our subflow once.

Plus the changes will immediately propagate to all the other flows that use our subflow.

Double benefit!

The takeaway?

Keep an eye out for any flow functionality you find yourself building over and over in different flows (when it does essentially the same thing).

It might be a good candidate to move into a subflow.

Hope this helps, and hope you have a great weekend!

Best,

Nick

Keep reading

See all posts →

Salesforce Saturdays

Join 1,036 Salesforce pros getting one 10-minute tip on Salesforce tech or career growth every Saturday.