When was the last time you took stock of the custom code in your Salesforce org? If it’s been a while, now might be the time to check on your triggers. Older Salesforce orgs may have evolved to include more than one trigger per object. This can cause unpredictable behavior, which is never a good thing. Does your Salesforce org have too many Apex triggers?
How Did We Get Here?
It happens sometimes. A request comes in for a new data automation feature in a Salesforce org. You’re in the middle of a different initiative, but because you’re the team’s designated Salesforce developer, you take a moment to fulfill this coding request. You write a small trigger and test class, deploy them, and you’re done. The requesting user is happy.
They’re happy until errors from exceeding governor limits start to crop up or reports of data anomalies start trickling in. It may take some time before anything unusual happens, and you may have forgotten about that little trigger by then, which can make resolving the problem frustrating for you and your team.
Take a look at your Apex code base. Do any of your objects have more than one active trigger for the same event? If so, combine those triggers. Otherwise, you will have no direct control over which one executes first.
How and When Do Apex Triggers Execute?
Let’s back up for a moment to review where triggers fit into the overall scheme of things. According to the Apex developer guide, “Apex triggers enable you to perform custom actions before or after changes to Salesforce records, such as insertions, updates, or deletions.”
Triggers are generally classified as “before” or “after” triggers. As you might expect from the name, “before” triggers execute before the data change is saved to the database, and “after” triggers execute after the change is saved but before it’s committed by the server. A data change may be an insert, upsert, update, delete, merge, or undelete action.
Which Operation Happens First?
In general, the Salesforce server performs basic data validation first. The details depend on whether a record was changed directly by a user or by an Apex application/API call. Then, the server executes the “before” triggers, re-runs most of the system validations, checks duplicate rules, saves the record, and executes the “after” triggers.
Assignment rules, auto-responses, workflow rules, processes, and other rules all come after the “after” triggers, but some automations, like workflow field updates, will fire “before update” and “after update” triggers one more time.
The real kicker here is this:
“The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed.” –Apex Developer Guide, “Triggers and Order of Execution”
If you can’t control the order of execution, then you may see unpredictable results. Of course, this depends on what your triggers do and what other data relationships your org includes. Nevertheless, unpredictable code is bad code.
How Do Governor Limits Apply?
Salesforce coding best practices include using one trigger per object on the same action due to execution governor limits. Just because each individual trigger stays well within the limit of 100 SOQL queries doesn’t mean there won’t be over-limit exceptions. Those governor limits apply to all of the code that’s processed. If a trigger causes a field update that activates a workflow field update that fires another trigger, the entire combination counts toward the limit.
This isn’t the place to delve into debug logs or the Limits Class. But there are tools that can help Salesforce developers like you manage resource usage in your coding; if you’re interested in more details, check out Salesforce’s Apex developer guide.
Why Is It Better to Use a Single Trigger Per Object?
OK, it doesn’t absolutely have to be one trigger per object as long as you have only one trigger per object for the same event. That said, it’s much easier to manage your code base as a whole if there’s one trigger per object.
As discussed in one of our previous blog posts about Salesforce considerations, that doesn’t mean you need huge, monolithic trigger classes. On the contrary, you need to organize triggers and helper classes into a coherent architecture. Place the handler methods into helper classes. There’s a great resource on trigger frameworks and best practices in the Salesforce Technical Library.
TL;DR
Over time, some Salesforce orgs may end up having multiple triggers on the same object and event. This is not in line with best Salesforce coding practices and can lead to governor limit exceptions and/or unpredictable data results. Too many Apex triggers can cause a lot of trouble. For optimal results, curate your code so that there’s only one trigger per object for the same event.
Susco was founded in 2006 and provides software solutions that help businesses run smoothly. We’ve been a certified Salesforce Partner since 2013 and have a wide range of Salesforce development capabilities within the platform. If you’re having trouble managing your org, setting up triggers, or dealing with more general Apex issues, contact one of our Salesforce developers by calling (504) 264-9343.