Best Practices for Implementing Salesforce Triggers

Salesforce triggers allow for automated actions on Salesforce objects in response to data manipulations, such as insertions, updates, or deletions.

They are similar to database triggers but call APEX code instead — a Salesforce back-end programming language, loosely based on Java (an excellent intro on triggers can be found here).

Building a functional Salesforce application without triggers is nearly impossible. However, if not implemented properly, triggers can quickly become unmanageable and difficult to maintain.

This post offers recommendations for keeping trigger code clean and maintainable, helping to reduce overall support and ownership costs.

Use One Trigger per Object

According to Salesforce documentation:

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.

Therefore, it’s best to follow the one-trigger-per-object rule when writing your own triggers. This doesn’t mean there will only ever be one trigger per object type — especially with multiple installed packages — but rather that your package should define only one.

This approach simplifies maintenance and troubleshooting. Additionally, it’s easier to disable or manage a single trigger if necessary.

Move Trigger Logic to Its Own APEX Class

Triggers have their own syntax that allows the mixing of declarations with APEX code.

However, it’s best to minimize the logic within the trigger itself and instead call an APEX handler class, for example:

trigger QuoteLineItemsTrigger on QuoteLineItem(before insert, before update, before delete, after insert, after update, after delete) {
    QuoteLineItemTriggerHandler.handleTrigger(Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap, Trigger.operationType);
}

Moving trigger logic to a class offers several advantages:

• It becomes testable with unit tests helping to eliminate errors.
• Maintenance is easier, as the logic can be divided into smaller, more manageable methods instead of one large block of code.
• Deployment is simplified, as it only involves classes. Otherwise, trigger code often needs to be commented out during deployment and then restored, a process that is cumbersome, error-prone, and may lead to longer downtimes.

Add a Bypass for Data Migration

Sooner or later, data migration and data quality becomes an issue in any larger project; therefore, it is important to accommodate for enabling and disabling triggers (either entirely or just selected logic) to enable migration of incomplete data.

This can also help with importing large data volumes quickly, and updating it post-migration.

Conclusions

Triggers are a fundamental part of Salesforce development and essential for nearly every Salesforce implementation. To ensure they remain error-free and easy to maintain, they must be implemented according to the best coding practices.

At Nexteris, we provides Salesforce development and advanced consulting services, including developing triggers and APEX for complex, high-volume data processing on Salesforce.

Contact us today to find out how we can help you!