Programmatic Concepts in Salesforce Flow

If you’ve been working with Apex for years and want to know about this new Flow tool, or if you’ve been working with flows for the longest time and are curious about Apex, then you’ll be happy to learn that there are a lot of shared fundamental concepts across the two tools.

I want to be very clear: Flow is not a replacement for Apex, and I don’t believe Salesforce will ever intend it to be. With that being said, there’s no denying that it is the ideal tool for some less complex automation and guided interaction, as it doesn’t require extensive programming knowledge. If you’d also like a brief introduction to the main differences between the two tools, I would highly recommend Andrew Cook’s article covering this topic!

A Brief History of Flow and Apex

Before we dig into the history of these tools, I want to direct you towards the Salesforce Release Notes Archive. I’ve referenced historic release notes quite a bit in this post, and all of this information can be found in Salesforce’s archive. Take a look at the history of Salesforce over the last decade or so if you enjoy seeing how other features have evolved. With that said, let’s go back to Flow and Apex history…

Our story began almost 20 years ago at Dreamforce ’06 with the announcement that changed the face of Salesforce forever. For the first time, developers would be able to harness the power of the Salesforce platform similarly to how Salesforce themselves had done so using two new tools: Apex and Visualforce.

Apex was to be an object-oriented programming language, similar to Java, that allows developers to customize Salesforce to their own liking. Although announced in 2006, it would take an additional two years of development before the Apex platform (later Force.com platform) was released to the public in the Summer ‘07 release.

Fast-forward to 2012, and we see the first iteration of Flow Builder, then called Cloud Flow Designer. This is the first time Salesforce has created a multi-dimensional point-and-click automation tool and given this much power to declarative admins. The largest flaw of this tool, although it can be understood given that it was released in 2012, was the fact that it was built using Flash. Over the next few years, the tool will see some major upgrades and improvements, such as the release of Flow Builder in Spring ‘19.

Similarities Between Apex and Salesforce Flow

Apex is a written coding language, and Flow is a declarative point-and-click tool, so how could the two possibly resemble one another? Although they are driven by different means – one by clicks, one by code – they share some fundamental similarities.

Both are driven primarily by variables, either individually or in a group. Collections of variables can be handled by iterating through them using loops. Additionally, functions can be triggered upon record creation, update, or delete. Let’s dive deeper into these concepts and how they apply to both Flow and Apex…

Variables

Records, text, numbers: these are all examples of the little pieces of data that are being processed by both Flow and Apex. They are used to store data and can be updated throughout the transaction.

Below is an example of some variables being initialized in an Apex Class:

And the same variables in Flow Builder:

Collections

Collections in Flow are similar to Apex lists – they both store multiple of the same variable in a single location. For example, a collection of leads in Flow is a record collection variable, and a list of leads in Apex (List<Lead>) also stores a list of lead records together.

Apex allows you to set up a new list in a single line, and you can optionally populate the list in the same line if needed.

In Flow, collections are used to group variables of the same type. In the example below, we can see a new variable called “Companions” that stores multiple leads together (allow multiple values (collection)).

Loops

Sometimes, you may be required to iterate through a list or collection and perform an assessment or change to each of the records within it. This is accomplished using loops in both Flow and Apex.

In Apex, you need to define what’s known as a “for loop”. Anything inside the {curly brackets} is run for each of the variables inside the list (in this case, every lead in the Companions list), as below:

The same functionality can be done in Flow with a series of elements as opposed to lines of code. The loop element is used to start the iteration over a collection, and the logic sits within the path that the loop generated, below the loop element.

Triggers

Flow has come a long way on the Triggers front since initially being released. Back in the old days, you would need to call a Flow from Process Builder, as there was no such thing as a Record-Triggered Flow. That was a long time ago, and Flow can now handle almost all six core contexts that Apex Triggers can, with the only exception being After Delete.

Additionally, each Record-Triggered Flow can only handle a single context, whereas Apex can handle multiple in a single Apex Trigger. Below is an example of a Record-Triggered Flow set up to handle when a lead is created. This is a Fast Field Updates Flow, so it will run before the data is saved to the database.

Below is an example of an Apex Trigger that is being set up on the lead object. It handles before and after insert, before and after update, and before and after delete. The Trigger uses IF statements to separate between the various contexts, with a comment in each that is being used as a placeholder for future functionality.

Summary

There’s a big difference between Apex and Flows, but at their core, they are quite similar. They are both means to automate complex business processes without requiring your users to do it manually. They both enable your organization to process records in bulk. They both can be Triggered by a record change. Yes, Apex is more powerful in terms of functionality and processing speed, and Flow has a much smaller learning curve, but they’re more or less the same in a lot of circumstances.

If you’re proficient in one tool and considering dipping your toes into another, you should consider the fact that you already have a good understanding of the fundamentals of how it works! If you can write a basic Apex Class, you shouldn’t have much trouble understanding the fundamentals of Flow. Similarly, if you’re a Flow master, you may find the basic structure of an Apex Class or Trigger to be familiar to you already. There’s the syntax for each tool that will require some study, but you’re already off to a great start!

If you’re interested in picking up Salesforce Flow and want to get a headstart, I would recommend having a look at the Ultimate Salesforce Flow Foundation course. This course was created to give you a good grasp of everything you need to know to get started in Salesforce Flow. It includes a clear run-down of the tool, how it works, and also some projects to test what you’ve learned throughout the course.