How to Block Recursion in Generic Trigger Handlers?

Question

Blocking recursion in Apex trigger handlers is a critical concern, especially when your handler is designed to cover all trigger operations and handle SObjects of any type. Recursion occurs when a trigger causes changes that subsequently invoke the same trigger again, resulting in an infinite loop. This is particularly problematic when operations like updates inside the trigger trigger another invocation of the same trigger.

Answer

To effectively prevent recursion in trigger handlers, there are several strategies you can adopt, based on the nature of your specific business logic and requirements. Here are a few techniques that can be used to block recursion:

1. Using Static Boolean Flags

One of the simplest methods for blocking recursion is to use a static Boolean flag that prevents the trigger from firing repeatedly. You set this flag to true when the trigger starts processing and reset it when the trigger finishes. This works well when you know the exact operations that might lead to recursion.
For example:

public class AccountTriggerHandler {
    static Boolean isInAccountUpdate = false;
    public static void afterUpdate(Account[] oldValues, Account[] newValues) {
        if (!isInAccountUpdate) {
            if (shouldDoUpdate()) {
                isInAccountUpdate = true;
                updateRecords(oldValues, newValues);
                isInAccountUpdate = false;
            }
        }
    }
}

In this example, the flag isInAccountUpdate ensures that the trigger doesn’t get invoked repeatedly due to the updates being processed within the trigger.

2. Rising Edge Trigger Pattern

A more refined approach is to use a “rising edge” trigger pattern, which avoids unnecessary recursion by processing only the changes that occurred in the current transaction. This is done by comparing the old and new values to determine if there were actual changes, ensuring that the trigger doesn’t re-process unchanged data.
Example:

public static void afterUpdate(Account[] oldValues, Account[] newValues) {
    Account[] oldChanges = new Account[0], newChanges = new Account[0];
    for (Integer i = 0, s = newValues.size(); i < s; i++) {
        if (recordChanged(oldValues[i], newValues[i])) {
            oldChanges.add(oldValues[i]);
            newChanges.add(newValues[i]);
        }
    }
    processChangedRecords(oldChanges, newChanges);
}

In this case, the trigger only processes records that have changed, reducing the likelihood of recursion because it doesn’t unnecessarily update records that have already been processed.

3. Using Sets for Multiple Record Updates

When dealing with updates to multiple records of the same type, a set can be used to track the records that have already been processed. This ensures that updates to the same record are not repeatedly processed, especially in cases where multiple DML operations occur in a single transaction.
Example

public class AccountTriggerHandler {
    static Set<Id> accountIds = new Set<Id>();
    public static void afterUpdate(Account[] oldValues, Account[] newValues, Set<Id> accountIdSet) {
        if (accountIds.containsAll(accountIdSet)) {
            return;
        }
        accountIds.addAll(accountIdSet);
        doMainLogicHere();
        accountIds.removeAll(accountIdSet);
    }
}

The accountIds set ensures that once a record is processed, it is not processed again within the same trigger execution, thus preventing unnecessary recursion.

4. Resetting Locks at the End of Trigger Execution

It is critical to always reset any “locks” (like the static flags or sets) at the end of the trigger to avoid issues such as preventing the execution of workflow rules, process builder updates, and approval processes. This is particularly important for managing scenarios where there are retries or updates involving more than 200 records.

For example, always clear any flags or sets to allow workflows or other operations to function as expected.

accountIds.removeAll(accountIdSet);

A proper strategy should handle partial updates, ensure only necessary updates are performed (using techniques like rising edge triggers), and minimize the time that locks are in place.

In Summary, There is no single perfect solution for blocking recursion in triggers. Instead, multiple strategies need to be combined based on the context of your business logic. Using static Boolean flags, rising edge triggers, sets to track records, and resetting locks are effective patterns that, when employed together, can reliably block recursion and avoid infinite loops. However, always ensure you handle edge cases such as retries and updates involving many records.

Kick Start Your Career with Real-Time Project-Based Salesforce Training

Our Salesforce Course is carefully crafted to provide a detailed understanding of the Salesforce platform, equipping you with the essential skills required to succeed in the CRM industry. The program includes key modules such as Salesforce Admin, Developer, and AI, blending foundational knowledge with practical experience. Through real-world projects and hands-on tasks, you will develop the expertise necessary to confidently tackle complex business problems using Salesforce solutions. Our experienced instructors ensure you gain both technical proficiency and industry-specific insights to excel in the Salesforce environment.

Along with mastering technical concepts, our Salesforce training in Hyderabad offers tailored mentoring, certification exam preparation, and interview coaching to boost your career opportunities. You will benefit from comprehensive study resources, practical project exposure, and personalized guidance throughout the course. By the time you complete the program, you’ll be well-prepared for certification exams and equipped with the problem-solving abilities and practical skills that employers value. Start your Salesforce career journey with us and explore a world of exciting opportunities. Enroll for a Free Demo today!