In this post, I shared a story where an implementation mixed a number of automation techniques with a trigger that wasn’t scalable in the long run. And that begs the question: When do you abandon no-code and opt for pro-code. Before I get into that, let’s highlight some guidance from Salesforce:
-
Same-record field updates into before-save Flow triggers instead.
-
Wherever possible, start implementing use cases in after-save Flow triggers rather than in Process Builder and Workflow (except for same-record field updates, in which case see point #1).
-
If you have high-performance batch processing needs or expect highly sophisticated implementation logic, use Apex.
With that guidance, I offer 3 points to consider:
-
Any object that has the potential for complex processing logic at scale should be in a trigger.
-
Any object that is at risk for data skew, now or in the future, should be considered for either Flow or a Trigger.
-
Any object that has potentially long transactional times should be done a Trigger.
Any object that is at risk for data skew, now or in the future, should be considered for either Flow or a Trigger.
In my opinion, the trigger is a safety valve in this situation to prevent unforeseen issues. Transactions on multiple child objects increase the likelihood of record-locking issues, so I would favor this solution to avoid any issues with Account skew or lookup skew.
Additionally, situations that could cause a detail record to update the master, or, situations that would cause an object to initiate an insert or update on another object without a clear line-of-site on long-term implications should be handled with a trigger (as should the subsequent transactions).
Any object that has before and after processing should be done in a Trigger.
For me, this is an indication of a potential for future complexities, the exception being cases where automation simply tacks on something simple. In my opinion, the trigger is future-proofing your implementation.
Any object that has potentially long transactional times should be done a Trigger.
All things considered, Apex triggers execute faster than Flow, so again the point here is to get into and out of the transaction as quickly as possible. The more complexity in the business process, the more important it is to get out of the transaction quickly.
I will be the first to admit that when I think through solutions, my brain first goes to Apex (or Lightning components) until a compelling reason to do something simpler emerges. And that line of thinking extends to the future state of the system as well.
I’d love to have your thoughts in the comments below. Let’s talk about it!!
