All Posts

Salesforce Coding II: Too Many Triggers?

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?

The Salesforce logo displaying the Apex development capabilities offered by Susco Solutions in Metairie, LA
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.

Recent Posts

Staff augmentation vs. project outsourcing: Which is right for your development project?

A year after the pandemic forced nearly every industry to go virtual, companies are increasingly investing in digital capabilities to support remote and hybrid work and provide critical continuity. According to Gartner, IT spending is poised to rise 6% this year to reach nearly $4 trillion worldwide.  For many IT leaders, these trends beg the […]

3 Tips for Building a Successful Custom CRM

Business spending on customer relationship management (CRM) systems is soaring, and for good reason. Once the domain of the largest enterprise businesses, a powerful CRM is now indispensable for teams of all sizes to build strong sales pipelines.  According to Salesforce, adopting a CRM can help companies increase lead conversion rates by 30%, sales productivity […]

How Mobile Apps are Helping Property Insurance Carriers Process More Claims

The Digital Age has placed unprecedented pressure on businesses, including insurance carriers, to modernize their processes. We’ve gathered a few of the ways insurance providers can use mobile apps to process more claims, and maintain a competitive advantage.