It’s no secret that Salesforce Flow Builder has come on in leaps and bounds in recent years. It far surpasses both workflow rules and Process Builder in terms of functionality, hence all automations need to be migrated to Flow.
But how does Flow compare with Apex? Can it replace Apex altogether? In this article, I’ll go through the differences between Apex and Salesforce Flow, how the Order of Execution impacts both tools, the limitations of both tools, and testing.
What Is Apex?
Apex is a programming language that uses Java-like syntax and acts like database stored procedures. Apex enables developers to add business logic to system events, such as button clicks, updates of related records, and Visualforce pages. There are a variety of tools in which you can write Apex, including the Developer Console, VS Code, and Salesforce Code Builder.
As Apex is a programming language, utilizing it will almost always require some sort of developer resource in your organization.
What Is Salesforce Flow?
As described by Tim Combridge in The Complete Guide to Salesforce Flow in 2023, Salesforce Flow allows you to build complex business automation using clicks instead of code. Flow Builder is the declarative interface used to build these flows.
Here comes the key difference between Apex and Flow: with Flow you do not need any developer resource in your organization to utilize the capabilities of the tool. An administrator (or even a super user in some cases) can build automations using Flow Builder. It takes a lot less time to get your head around than Apex, and it is much more visually appealing.
Order of Execution
The Order of Execution is something that needs to be considered depending on whether you are using Apex or Flow. There are two important points when it comes to the Order of Execution (as you can see in the below graphic):
- Flows run before Apex triggers.
- Apex triggers can also run multiple times in a single transaction.
You should take both of these points into account when architecting your business workflow to make sure everything runs as expected.
Limitations
With Flow Builder, there are certain limitations depending on the type of flow that is being created. As you can see in the below table, a before-save triggered flow has more limitations than an after-save triggered flow. There are also certain things (such as complex list processing and custom validation rules) that simply cannot be done with Flow alone.
In terms of the limitations of Apex, the only real one is that of resources. Developer resources can be quite costly for an organization. However, in terms of functionality, Apex doesn’t have any limitations. If you have a developer who can write the right code, anything is possible.
Testing
With Apex, testing is ‘part and parcel’ of development. You simply cannot push any Apex code from a sandbox into production without a passing test class.
With Salesforce Flow, this currently isn’t the case. As ill-advised as it is, you can build and activate a flow directly in production if you want to. I say currently because I would imagine this will change in the future, and testing with flows is likely to become compulsory, as it is with Apex.
As covered by Tim Combridge in How to Test Your Salesforce Flow, there are a number of ways that you can test your flows. It is a good idea to get into the habit of testing your flows now so that if and when it does become compulsory, you already have the knowledge to do so.
Summary
I hope this article has helped in terms of understanding the differences between Salesforce Flow and Apex. From the resources you have available to the limitations of each tool, ultimately you need to choose the tool that is right for your organization. Salesforce Flow Builder is a much more powerful automation tool than those it is replacing, but it is still some way off from being able to replace Apex altogether.
