Please don’t use the Process Builder for that
The low-code revolution with its point-and-click solutions has a pretty clear message for us developers: avoid Apex whenever possible. The guidelines dictate that solutions that write Apex for something that could have been done through a point-and-click tool are inferior.
Most of the time, the advice is sound. Unfortunately, the whole message around low-code and point-and-click makes it too easy for us to miss the following immensely important message which you’ll find somewhere deep inside the developer guide:
When you’re all revved-up about low-code solutions and ready to point-and-click your way out of every problem, it’s easy to glance over the above. Just to make a point about how important it is, I’m going to post a zoomed-in picture of the above:
Now let’s talk about why.
Isn’t low-code better?
Yes, it is. Low-code solutions are always good. They’re easier to maintain, faster to implement, and they’re what make low-code platforms like Salesforce so powerful. When we’re looking to solve a problem through Salesforce, our first instinct should be to use a no-code or a low-code solution.
The pitfall that we’re looking at here happens when the word “low-code” compels us to write workflow rules or create a process on an object that has or will have a trigger running on it as well.
The good design choice is this: If requirements around an object are complex enough to warrant an Apex trigger now or in the future, stick only to Apex triggers.
And what really is wrong with mixing the automation tools?
The first problem is that you can’t control the order of execution.
Imagine that you have a requirement complex enough to warrant a before insert Apex trigger to update some fields. You also have a Workflow Rule running that updates a field value, and you need the workflow update before your trigger executes.
You code it and it runs fine. Looks like the workflow rule updates the value before your trigger runs. You did get lucky though — and this is where you realize that mixing automation tools can be a problem: a process would not have executed before the trigger. But for now, everything’s well, users are happy, your boss loves you and you love your boss.
But beneath those smooth executions and flawless field updates, there is an ugly truth waiting for its moment to alienate your users and destroy whatever’s going on between you and your boss: Triggers execute before workflow rules.
Wait, what?
But then why did your code work in the first place? Because a workflow field update causes triggers to re-run. And you probably won’t discover that until you’re coding something else.
I don’t know about you, but I feel that the above scenario is uglier than a Blobfish. I’m writing this at 9 pm and just the thought of the above is going to prevent me from having a good night’s sleep.
There are other problems too: Your solution becomes harder to understand because logic is distributed in multiple places, more error-prone because you don’t get the same level of testing, debugging and error-handling, and also trickier deployments because you’re now dealing with a new metadata item per-version, not to mention the manual step of activating the process after every deploy.
With that in mind, let’s lay down some …
… ground rules
We find broadly two kinds of projects in the low-code world: Ones built and supported by professional software developers, and ones supported (and maybe also built) by not-software-developers who understand the point-and-click side of Salesforce.
Avoid processes and workflows for developer-supported projects
If your project is complex enough to require constant support from Apex developers, you may want to avoid processes and workflows altogether. Anything you do with the Process Builder is never too hard with Apex, and creating processes puts you at risk of having to migrate it all to Apex if the need for triggers arises in the future.
Use processes to their fullest for non-developer-supported projects
If you conclude, however, that the application you’re building will be supported by admins or citizen developers who can only work with the point-and-click side of Salesforce, you have a very good use case for using only the process builder, going as far as calling Apex methods from the process where necessary instead of a trigger.
For projects like these, calling Apex through a process instead of writing a trigger leaves the door open for point-and-click developers to extend the application because they can control when exactly your Apex executes.
Favor processes over workflow rules
If you choose to use point-and-click automation on an object, choose to work with the process builder instead of workflow rules when you can. This also means migrating existing workflow rules to the process builder because you want only one automation tool.
Is this object ever going to need an Apex trigger in the future?
Even if you have a project that you know will require support from software developers — and for some reason you really, really want to — you would be just fine using the process builder if you can be certain that your object won’t require Apex in the future. Be careful though: if requirements were that easy to predict, we would all happily be following the waterfall model.
Remember to migrate workflows to processes or processes to triggers
If you’re working on a complex project, chances are that you’re dealing with objects that have all three on one object. If your automation tool of choice is the Process Builder, you should migrate workflow rules to processes and if you have apex triggers, you should migrate processes and workflow rules to triggers.
There is for sure a cost associated with that migration, but treat it as any other technical debt. The cost of not migrating to the right automation tool is probably a lot more than taking the time to fix things early.
The Salesforce world is filled with Objects that have a bunch of workflow rules, a couple of processes and (hopefully just one) trigger. Things can get ugly really fast if we mix of all of that, and chances are you’ve lost sleep over a bug caused by mixing these automation tools.
The verdict from Salesforce is clear: Only use one automation tool per object. And the best tool might just be Apex.
