How to avoid recursion in Salesforce

Published by

on


Recursion is a major problem in applications. It’s always better to keep the Recursion in mind before you implement any business automation requirement.

Sharing some of the general strategy to avoid/fix recursion:

  1. Use a Static Variable or Flag: One common approach is to use a static boolean variable as a flag to track whether the trigger has already been executed. This flag can prevent the trigger from executing again within the same transaction. For example:

Apex Class

public class checkRecursive {
     Public static Boolean alreadyExecuted=false;
}


Apex Trigger

Trigger ContactTrigger on contact (after update) {
    if(!checkRecursive.alreadyExecuted) {
           checkRecursive.alreadyExecuted = true;
           //...call handler
    }
}

Static in Salesforce are per transaction, so the value will be true only for the current transaction. It will be initialized to true for other transactions. Don’t think of static in Java term where static values persist till the class is loaded into memory.

  1. Utilize a Handler Class: Create a handler class to manage trigger logic and state. By centralizing the trigger logic in a separate class, you can better control the execution and avoid unintended recursion.
  2. Use Recursion Control Logic: Within the trigger, include logic that prevents the trigger from executing when certain conditions are met. For example, you could check whether the trigger is being fired by a user update rather than a system update.
  3. Trigger Frameworks: Utilize trigger frameworks or patterns that have built-in mechanisms to handle recursion. These frameworks often provide a way to control the execution flow and prevent recursive triggers.
  4. Remove Workflow Rules or Process Builder: Remove any WF or PB in your application and move the logic to either Trigger/flow. But if you are moving logic to flow then remember flow always runs 1st, so design accordingly.
  5. Bulkify Your Code: Ensure that your trigger logic is bulk-friendly, meaning it can handle multiple records at once. Bulkifying your code helps reduce the likelihood of hitting recursion limits.
  6. Test Thoroughly: When developing triggers, always test them with different scenarios, including bulk operations, to ensure they don’t inadvertently trigger recursion.
  7. Consider Trigger Order: If you have multiple triggers on the same object, consider the order of execution. Sometimes, altering the order of trigger execution can help control recursion.
  8. Limit Cross-Object Triggers: Be cautious with triggers that involve multiple objects. Changes to related objects can trigger additional actions and lead to recursion.
  9. Verify/Validate Business Cases: It’s always to do a health check on business requirements which need automation. Remove any unnecessary implementation or try to merge the automation logics. With day by day we gets busy implementing requirements and sometimes forgets if the new requirement can be merged with existing implementation or to revisit the existing design to incorporate the new one.

Remember that preventing recursion is just one aspect of writing effective and efficient trigger logic. It’s important to design your triggers with care, considering not only recursion but also bulk processing, governor limits, and overall performance.