That is the question. Whether ’tis nobler in the mind to build the processes and automations declaratively or to write apex and a sea of code.

Now that I’ve successfully butchered Shakespeare, let’s talk about automation. There’s been a lot of ongoing discussions over the many months on the “best” way to automation in Salesforce. “We should use Flow!” scream one group. “Code is the way!” screams the other group. In truth, there are pros and cons to both choices. Some of the benefits are technical and some of the benefits are organizational.

I am one of those lucky folks that have been building automation both with code and without (declaratively) code. I’m familiar enough with both solutions that each time I have an Automation Use Case, I can ask the question “To Flow or To Code?” and come up with an answer.

You need to Know when to Flow Them; Know when to Code Them.

To Flow or To Code

There are some basic questions I ask to help determine if I build a Flow or write code.

• Does this require a user interface or will it be automatic?
• How many records could be processed in a single transaction?
• Who will be maintaining the automation?
• How often is this automation/process need to be updated?
• Is the process logic complicated?

There are advantages and disadvantages of both methods.

Pros and Cons

Apex Unit tests are something you can write for Flow and are mandatory for Apex Code. A unit test is only as good as it is written – so just having a test doesn’t mean it’s properly testing functionality. There are more pros and cons for both system and your perspective may consider different things to be benefits or disadvantages. This is my list off the top of my head.

How to Choose 

My personal guideline is any automation that involves 500 or few records and does not have complex logic I always attempt to build in Flow first. The main watershed decision is having greater than 500 records – with the exception of Scheduled Flow solutions.

There are other considerations. An organization may not have someone who knows how to write apex code and doesn’t – or isn’t willing – to have the budget to outsource the project. In those circumstances even when the logic is very complex, the best choice for that organization – right now – is to build it in Flow. The reverse can also be true. An organization may have someone who’s very adept at Apex Code and no one who understands Flow. For this organization the best choice – right now – is to do it in Apex Code.

My point is that this isn’t a 2 sided choice. There’s more nuances than “Flow is good” or “Code is best!” mentalities.

Let’s use a simple, albeit a very dumb use case. At my organization, we want to always have the Sales Price be $100 for all our products. If we’re going to use automation, do we use Flow or Code?

Example of the same process in Flow and in Code

On the left, you can see the Flow. It’s colorful, you can follow it fairly easily with proper naming conventions. On the right, you’ll find Apex Code. You can easily follow it thanks to comments and it is much more compact compared the Flow. What we don’t see is the Unit Tests that need to be created for the code above. In my experience, proper Unit Tests following best practices can often be longer than the code it’s testing. 

We can’t take a look at this and make a choice on what’s the best decision. Do I have someone who can write and maintain Flow? Do I have someone who can do the same for Apex Code? How many records could possibly be in a transaction? Chances are Opportunities are going to have hundreds of products, but is there ever a time multiple Opportunities are updated and would then call this automation? If my organization frequently does data imports and updates to Opportunities, I would lean towards Apex Code because it is “bulkfied” differently and can handle thousands or more records. 

As a consultant at Better Partners, I often will choose the declarative method. Sometimes it’s because the customer is on Professional Edition of Salesforce. Most times it’s because their internal resource is able to understand and maintain a Flow than Code. In those circumstances, unless the use case is really outside of Flow’s capabilities, I choose Flow for the automation solution.

Sometimes You Can Have Your Cake and Eat It Too

One of the strengths of the Salesforce platform is flexibility. You don’t always have to choose Flow or Apex Code. When you have a resource for both options, you have the option of doing both. Apex Code developers can write functionality that is invocable by Flow. This means extremely complex logic or challenging queries can be off-loaded to Apex and some of the business logic can remain in Flow. It really depends upon your use case and the resources & their capabilities at the organization. 

You Can Have Complex Logic In Flow

Here’s an example of some amazing work that was done in Flow. Thanks to Sarah Pilzer (https://twitter.com/spilzer/status/1496927603755737094) for sharing this amazing work.

Where did “Flownatic” come from? Dreamforce 2014: Know the Flow Code: https://www.youtube.com/watch?v=0NNBBTLD5U8

Midwest Dreamin’ 2018 Know the Flow Code: https://www.youtube.com/watch?v=QTiYnCCuG1E