Influencers and Subflows

Hello folks,

Spring 22 is approaching fast. The release notes are out, and there are a bunch of exciting flows coming for flows. Let’s dive into those in the next issue of the newsletter, though. I will write about subflows today.

But before I dive right in, I need to tell you about something quite extraordinary that happened to me this past week: Salesforce Ben, one of the most popular publications about Salesforce, published a post that listed the top 20 Salesforce influencers for Salesforce, and to my surprise, I happen to be one of them. I heard something like this was coming, but I did not expect to be on a list of 20. I thought if they made a list of 50 folks to follow over 50, then I’d be on it. Thanks for all your support. I am grateful. You can find the full list here.

Subflows are not for everyone. They have their place in the flow architecture, and they are helpful, but there are many misconceptions around them. What they should not be used for, in my humble opinion, is as follows:

  • To get a fresh empty canvas to organize your flow better.
  • To bring all the logic for all the record-triggered flows together for one single object.
  • To circumvent governor limits, e.g., force a separate transaction.

The concept of subflows is not new in the programming world. In programming, you can have various different code logic executing the same code in multiple places. What you would typically do in that case is that you’d separate out this piece of code and call it from within your code whenever it is needed. In summary, good reasons to use subflows are:

  • Have a need to repeat the same logic within various flows.
  • Flow logic is expected to be revised over time.
  • Ease of maintenance.

What are subflows? Subflows can be autolaunched, or screen flows. Screen subflows can be called from screen flows. Autolaunched subflows can be called by every other flow type with the exception of before-save record-triggered flows (a.k.a. fast field updates, and this may change in the coming releases).

There is no setting that makes a subflow a subflow; they are essentially flows that you call from within another flow by inserting the subflow element.

For an active flow to work without problems, the subflows need to be activated as well.

Unless forced to execute in a different context, subflows will run in the same context that your main flow runs in: user, system, or system without sharing.

To understand better what a subflow is, you can think of them as aliases that call another sequence of logic that will be pasted into your main flow when it runs, and the whole logic will be executed as a whole.

Subflows often have input and output parameters. The way you set this up is like any other autolaunched or screen flow: You check input and/or output checkboxes when you set up your variables.


Let me give you two examples:

  • Address entry screen subflow: You may have certain custom checks, validations, and error messages that you need to set up whenever the user enters an address. In most cases, you will have many different flows, sometimes the same flow in two different locations calling for an address entry. You can create an address entry subflow and pass the values back to your main flow after the user enters them correctly.
  • You may need to calculate the time it took for your organization to close cases on all cases under one single account and take an average of the duration. If you need to do this multiple times in multiple flows, it may be a good idea to build this as a subflow. You can pass the accountId to your subflow and get back an average duration number back that you can use in your main flow.

Let’s go back to my original bullet points of wrong reasons for using subflows, and play Mythbusters:

  • Fresh empty canvas: Unless you plan to use your subflow multiple times in different flows, subflows do not give you simplicity; they may increase complexity.
  • One giant record-triggered flow: This means you will do everything after-save. The outcome will be one giant flow with subflows, potentially less performant and harder to maintain. Salesforce is giving us tools to manage multiple Record-Triggered flows on one object. More on that will come in next week’s issue.
  • Governors limits: This is an interesting one. Louder for the ones in the back: Subflows do not force a separate transaction. Main flow and all subflows execute in one single transaction. There is literally nothing that helps you beat governors limits when using subflows.

Now that I got that off my chest, let me give you a few links.

Recently published content:

  • Salesforce Break website is up and running. Exciting: Your one-stop location for everything related to flows. I started posting the previous issues of the newsletter on the Salesforce Break blog. You can reach it here.
  • I posted a list of all the Salesforce blogs I follow. Please read it here.
  • I published a short video that includes a sneak peek into Spring 22 flow features. You can watch that here.

Enjoy your flow learning journey.

P.S. Originally published on 01/09/2022.

Read the previous issue of the newsletter here.

Read the next issue of the newsletter here.

Subscribe to the weekly educational Salesforce Flow Tips newsletter here.


Salesforce Blogs I Follow

Here are the links I accumulated in my WordPress reader over the years.

The selection criteria are not very scientific and super simple. The site needs to be a Salesforce-related blog. I need to have come across the site somehow. And the platform needs to play well with the WordPress reader. Some platforms do not issue the content in the format that can be displayed in the WordPress Reader.

If you find a link has been added by accident and needs to be removed, or you have a link that you want to add please read the instructions at the end of the post.

Aaron Saray | Milwaukee
Adam To Architect
All About Salesforce
Analysis Paralysis
Another Salesforce Blog
Apex and Beyond
Ashish Agarwal
Audit9 – Cloud Architects
Automation Champion
Bir Bilgisayar – Tugce
Blog Martina Humpolce
Bob Buzzard Blog
Bob Buzzard Stack
BRDPro Blog
Certify CRM Blog
Chris Zullo
Cloud Architecture
Cloud Johann
Cloud Sundial
Coding With The Force
Douglas C. Ayers
Englhard Consulting LLC
Exploring on Salesforce
Force Lightning
Force of Anarchy
Force The Cloud
Gorav Seth
Jenna Molby
Jenwlee’s Salesforce Blog
Jordan Nelson
Jyothsna Bitra
Le Nguyen’s Blog
Let’s learn something
M Hamza Siddiqui
Managing Equitable,
Effective Teams
Matt McGuire
Meenakshi Kalra
Meera R Nair – Salesforce
Meighan Brodkey
MT-ing My Head
Nick’s Salesforce Musings
Paarth Jolly
Peter Knolle
Quirks of coding and
other related tidbits
Rampalli Sarma’s blog
Salesforce 9 to 5
Salesforce Ben
Salesforce Blazer
Salesforce Bolt
Salesforce Chris
Salesforce coding lessons
for the 99%
Salesforce Dad
Salesforce Diaries
Salesforce Facts by
Salesforce Memo
Salesforce Time
Salesforce Tips
Salesforce Weekly
Sara Has No Limits
Sarah’s blog
SFDC Learner
Sforce Maximizer
Sunshine and Other
Unhandled Exceptions
Terry’s Tidbits
The Data are Alright
The Spot For Pardot
The WeinBlog
Tidbits For You
Todd Halfpenny
Trailhead Baby
Vivek M. Chawla
Women Code Heroes

The list is alphabetically sorted by the title.

If you find a link that has been added by accident and needs to be removed, please comment below.

If you have a link that you want to add, please first make sure that the link is for a blog that:

  • Has at least ten posts.
  • Published a post in the last six months.
  • Includes educational content, and it is not all about selling a product or service.

You can add links that fit these criteria below in the comments, and I will review and approve intermittently.

I may even update the master list at some point.