Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

What is Salesforce Flow?

02 Dec 2022
💬 EN

Table of Contents

Salesforce’s Flow is, more or less, a programming language that lets you do things in Salesforce when you run the programs you wrote in it.

Rather than writing code, you program Flow by building flowcharts in a tool inside of Salesforce called Flow Builder.

Types of Salesforce Flow

There are 3 major kinds of Flow you can program with Salesforce Flow Builder:

  1. Screen
  2. Triggered
  3. Autolaunched

What is a Screen Flow?

A Screen Flow, in Salesforce, is an interactive user interface that humans can control in real time by clicking and typing.

Here’s a great use for building a Screen Flow:

You’d like to build a custom data entry form that lets staff enter a customer’s details just once, but when they click “save,” propagates those details to more than 1 Salesforce object at a time.

What is a Triggered Flow?

A Triggered Flow, in Salesforce, does its work in the background of Salesforce, without humans explicitly watching it run, in response to one of 3 things:

  1. a schedule like “every morning at midnight”
  2. Salesforce record data edits like someone creating, editing, or deleting a Contact record
  3. a slightly advanced concept called a “platform event”

What is an Autolaunched Flow?

An Autolaunched Flow, in Salesforce, also does computations or Salesforce work in the background, without humans explicitly watching it run.

However, when you create and save one, you leave unspecified exactly what is going to make it run.

You promise yourself that you’ll just worry about that later.

  • Maybe one of your developers will end up making it run from some Apex code.
  • Or … maybe you could end up making it run from some other Flow.
    • You might end up running it from a Screen Flow.
    • You might end up running it from a Triggered Flow.
    • Believe it or not, you can even run an Autolaunched Flow from another Autolaunced Flow.

Here’s a great rule of thumb for building an Autolaunched Flow:

If a business process exists at your company that predates your adoption of Salesforce and/or would outlive your company ceasing to use Salesforce, separate that business process out into its own standalone Autolaunched Flow.

My company’s sales rep territory assignment flowchart predates our adoption of Salesforce and would endure even if we stopped using Salesforce.

What is a Subflow?

Running an Autolaunched Flow from another Flow is probably the most common, well-known way to run an Autolaunched Flow, and when we do it that way, we refer to the Autolaunched Flow as a subflow of the Flow from which we’re running it.

This pattern is so common that I have a slightly inaccurate habit of saying “subflow” when I mean Autolaunched Flow because it’s shorter and rolls off the tongue better.

Technically, though, while all Subflows are Autolaunched Flows, not all Autolaunched Flows are destined to be run from other Flows, which means they don’t all end up as Subflows.

The main thing to remember is that when you’re building an Autolaunched Flow, you don’t even have to think in advance about what exactly is going to be responsible for making it run.

You just worry about programming what it’s going to do when something does eventually get around to running it.

In defense of Flow

Flowchart-based point-and-click programming tools have become very robust programming languages since the mid-2010’s.

This strikes me as very natural, because programmers have always diagrammed their plans for writing programs as flowcharts before starting to write code.

Humanity wrote code by hand before the mid-2010’s because until recently, we simply didn’t have the infrastructure in place to offer programming languages that are flowcharts. (Heck, we used to have to write code with paper and a hole punch.)

  • In the 2000’s, point-and-click software (like Flow Builder) moved from being primarily run on individual desktop computers to being primarily run in a web browser (where it’s much better-positioned to “phone home” to a server like Salesforce and do nifty things – like become a runnable program – in the background).
  • In the 1990’s-2010’s, server parts, computer speeds, data storage, and network speeds grew to support what’s known as “the cloud.” This makes it plausible to reliably offer web-browser-hosted software to the entire world and trust that it won’t crash when it gets popular.

Please don’t let anyone try to gatekeep your use of Flow and make you feel “less than” as a programmer. Salesforce programmers didn’t write Apex before Flow because it’s inherently better in any way. We wrote a lot of Apex because we didn’t have Flow like it’s built today.

Harvard University started teaching its introduction to computer science course with a flowchart-based point-and-click programming language (MIT’s Scratch) rather than a handwritten programming language.

When you apply decades-old programming best practices to Flow – like “don’t repeat yourself” (e.g. using Subflow) and “application service layers” – that makes you very, very good at software engineering. Don’t ever let anyone tell you otherwise!

These days, Zapier, If This Then That, and Microsoft Power Platform are a few other large companies that are also making flowchart-based programming languages for the masses.

Hopefully, computer education for the masses will catch up quickly with the explosion of of flowchart-based programming languages. I’d love to see more computer science and software engineering best practice books, blogs, and self-help videos that teach intermediate and advanced programming concepts from the 1970’s-2000’s, but entirely demonstrated in flowchart-based programming languages.

Know of any? Please leave your favorite recommendations in the comments.

In the meantime, make sure you keep an eye on:

--- ---