Trigger Helper Class Pattern

Trigger Helper Class Pattern

According to “Best Practices” suggested by Salesforce, we should always use a Helper Class (Apex Class) with a Trigger.

It is a design pattern which makes it easy to maintain the code in the long term.

Common Avoidable Practice:

Salesforce record changes → Trigger containing all the performing code, executes → End

Best Practice

Salesforce record changes → Trigger calls out to one or multiple classes → Class contains the performing code which executes → End

Example:

trigger accUpdate on Account(before insert, after insert, before update, after update) {
            if (Trigger.isBefore) {
                If(Trigger.isInsert) {
                    // execute first trigger 
                    AccTriggerHelper.firstMethod(Trigger.new);
                    // execute second trigger 
                    AccTriggerHelper.secondMethod(Trigger.new);
                    // both of these trigger will follow the execution order 
                }
                Else
                if (Trigger.isUpdate) {
                    // write the code for before update 
                }
                Else
                if (Trigger.isDelete) {
                    // write the code for before delete 
                }
                Else
                if (Trigger.isUndelete) {
                    // write the code for before undelete 
                }
            }
            Else
            if (Trigger.isAfter) {
                If(Trigger.isInsert) {
                    // write the code for after insert 
                }
                Else
                if (Trigger.isUpdate) {
                    // write the code for after update 
                }
                Else
                if (Trigger.isDelete) {
                    // write the code for after delete 
                }
                Else
                if (Trigger.isUndelete) {
                    // write the code for after undelete 
                }
            }
        }

Let’s understand the concept of the Trigger Helper Class Pattern with an example of a Trigger on Account object, which fires for all the Trigger events.

Handling Recursion In Triggers

Recursion in Triggers happens when a Trigger is called repeatedly, resulting in an infinite loop.

To counter recursion, we need to:

1. 1. Create another class called RecursiveTriggerHandler.

1. 1. Make use of “Static” variables.

Example:

trigger BranchTrigger on Branch__c(before update) {
            if (RecursiveTriggerHandler.isFirstRun) {
                RecursiveTriggerHandler.isFirstRun = false;
                // Call Helper Class method 
                BranchTriggerHelper.firstMethod(Trigger.new);
            }

The first instance of the Trigger is run and if this variable is true, the logic in the Helper Class executes.

Other Best Practices for writing Triggers:

1. 1. Always create only one Trigger per object.

1. 1. Create logic-less Triggers and use Helper Class Design Pattern in which the helper class will contain all the logic.

1. 1. Create context-specific handler methods in the Helper Class.

1. 1. Bifurcate “insert” and “update” Trigger logic contexts and create two different methods in the Trigger’s helper class.

Example:

 trigger PositonTrigger on Position__c(after insert, after update) {
            if (Trigger.isAfter && Trigger.isInsert) {
                PositionTriggerHandler.handleAfterInsert(Trigger.new);
            } else if (Trigger.isAfter && Trigger.isUpdate) {
                PositionTriggerHandler.handleAfterUpdate(Trigger.new, Trigger.old);
            }
        }

Some important points about triggers:

• • The order of execution isn’t guaranteed when having multiple triggers for the same object with the same events.

• • When a DML call is made with “Partial Success allowed” then more than one attempt can be made to save the successful records if the initial attempts result in errors for the same records.

• • Some operations do not invoke triggers:

    • • Cascade Delete

Records that don’t initiate a delete event don’t cost trigger execution.

• •  Cascade update of child records that are re-parented as a result of merge operation.

• • Mass campaign status changes.

• • Update account triggers do not fire before and after a business account record type is changed to a person account record type or vice versa.

• • Before trigger associated with the following operations are fired during lead conversion only if validations and triggers for lead conversion are enabled in the organization

    • • Insert an account, contact & opportunity
    • • Update of account and contacts. 

• • Fields not available in before insert  triggers

    • • Opportunity.Amount
    • • Opportunity.isWon
    • • Opportunity.isClosed
    • • ID (for all records)
    • • CreatedDate and LastModifiedDate

• • Fields not editable in after triggers

    • • Event.WhoID
    • • Task.WhoID

• When an opportunity has no line items then the amount can be modified by a before trigger.

Next Chapter