Flow vs. Apex is the Incorrect Debate

The Salesforce ecosystem has been great in driving the no-code/low-code movement. In true “No Software” fashion, they have put a great deal of effort into empowering Administrators to accomplish what Developers were typically needed for.

In 2010 when I was first getting started with Salesforce, we had Apex and Workflow Rules to drive any sort of automation. There was no Trailhead at the time, documentation was intimidating, and code was done in Eclipse – which was enough to kill my Macbook Air.

Force.com Eclipse Plugin

Due to necessity, I dove into Apex because I needed Triggers to have any hope of delivering features.

Over time though, with the explosion of Process Builder and the iterations of Flow Builder, it seemed a mantra emerged.

Triggers and code may break my bones, but clicks will never hurt me.

Developers jump quickly to code, shunning Flows as less efficient. I am here to tell you it doesn’t have to be one or the other; it can be both.

I am not saying that engineers need to give up Apex – sometimes it’s quicker to write Apex than fire up Flow Builder.

I am also not saying that Administrators need to learn to code. I am saying the opposite; if you’re an Administrator and code doesn’t interest you, don’t worry about it. But, knowing what is possible with a Lightning Web Component or a callout will help you in the long run.

Administrators and Developers Working Together Deliver Wonders

Development and Admin teams partnering together deliver remarkable features. Flows can be built that handle most of the logic in automation that calls an Apex action to interact with a third-party API or process complex logic.

An Invocable Method

You can undoubtedly build flow elements if you need to parse a multi-select picklist. Still, the readability of the Flow suffers as multiple steps are required. Instead, you can call an Invocable Method through an Apex action, reducing the amount of complexity and ensuring your Flow is readable.

The Best Solution is the One That Works

Whether you choose clicks or code, the best solution is the one that delivers value to your users. We shouldn’t agonize over what solution to implement, as chances are we will use what we are most comfortable with.

In smaller organizations, we may not have the resources available to implement the best case solution. We are constrained by budgets, by time, and the demands of our business units.

We may be dissuaded when we read blogs or go through the Trailhead community by posters saying what best practice is or to leverage other tools. But, keep in mind that the resources of Enterprise clients often outweigh ours.

For instance, we know that for UAT, the best practice is to utilize a Full Copy Sandbox. This way, our data mimics Production, and we can identify any issues before releasing it to Production. But, I know of a few SMB customers that have the budget for a Full Copy or even a second Partial Copy sandbox.

So, we do what is best for our organizations, a best practices lite approach. We know what we should do and accommodate for our variables.

The same rings true for which automation tool we choose to use.

Clicks AND code, not Clicks OR Code

The true answer is we should leverage clicks and code. The two are not mutually exclusive.

We may see more Triggers and other Apex Classes in large enterprise organizations to handle automation cases. In some cases, we see Triggers more due to the technical debt incurred before features such as Process Builder and Flow were released.

Larger enterprises tend to also have requirements to connect to ERPs, fulfillment platforms, or other resources. While we are seeing a need for interconnectivity at the SMB level, we tend to choose applications that have native integrations, so no code is needed.

In the end, Developers should embrace Flow as a tool in their toolbox. Administrators, yes, you can reach for Flows to solve your issues, but don’t forget that Developers can be a great sounding board for how to approach a problem. If we can learn what tools our Administrators are using, we can empower them.

What has been your favorite solution that you’ve built using both Declarative and Programmatic solutions? I would love to hear them.

1 comment

Leave a Reply

Your email address will not be published.