function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
RockzzRockzz 

what is a recursive trigger? how to handle it?

what is a recursive trigger? how to handle it?

 

Thanks,

Munna.

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

A recursive trigger is one that will end up calling itself again. For example, if you have a trigger on accounts that updates contacts, and a trigger on contacts that updates accounts, it is possible that the account update could update contacts that would in turn update the account... this will cause errors. The specific solution to this depends on the situation, but usually it will suffice to have a "trigger guard" that will keep the trigger from running a second time. It can look like this:

 

public class TriggerGuard {
  public static boolean accountguard, contactguard;
  static {
    accountguard = contactguard = false;
  }
}

 

trigger upAcc on account (after update) {
  if(!TriggerGuard.ContactGuard) {
    TriggerGuard.AccountGuard = true;
    // update the contacts.
  }
}

 

trigger upCon on Contact (after update) {
  if(!TriggerGuard.AccountGuard) {
    TriggerGuard.ContactGuard = true;
    // Do something to update the accounts.
  }
}

In this manner, each trigger advises the other if it is already in progress, thus preventing a recursive call that will ultimately fail.

 

That said, this sort of design isn't always necessary. Sometimes the trigger updates fields conditionally, and those conditions prevent recursion.

All Answers

sfdcfoxsfdcfox

A recursive trigger is one that will end up calling itself again. For example, if you have a trigger on accounts that updates contacts, and a trigger on contacts that updates accounts, it is possible that the account update could update contacts that would in turn update the account... this will cause errors. The specific solution to this depends on the situation, but usually it will suffice to have a "trigger guard" that will keep the trigger from running a second time. It can look like this:

 

public class TriggerGuard {
  public static boolean accountguard, contactguard;
  static {
    accountguard = contactguard = false;
  }
}

 

trigger upAcc on account (after update) {
  if(!TriggerGuard.ContactGuard) {
    TriggerGuard.AccountGuard = true;
    // update the contacts.
  }
}

 

trigger upCon on Contact (after update) {
  if(!TriggerGuard.AccountGuard) {
    TriggerGuard.ContactGuard = true;
    // Do something to update the accounts.
  }
}

In this manner, each trigger advises the other if it is already in progress, thus preventing a recursive call that will ultimately fail.

 

That said, this sort of design isn't always necessary. Sometimes the trigger updates fields conditionally, and those conditions prevent recursion.

This was selected as the best answer
RockzzRockzz

Thanku so much.

 

Thanks,

Munna
Ajinkya DhasAjinkya Dhas
Recursive Trigger
When you want to write a trigger that creates a new record as part of its processing logic. However, that record may then cause another trigger to fire, which in turn causes another to fire, and so on. You don't know how to stop that recursion.

Using a static variable in an Apex class to avoid an infinite loop. A static variable is local to the context of a web request (or test method during a call to runTest()), so all triggers that fire as a result of a user's action which has access to it.

Let's understand some scenarios...

Scenario :
Suppose there is a scenario where one trigger perform an update operation, which results in invocation of the second trigger and the update operation in second triggers acts as triggering criteria for triggers one.

Apex Class :
============================================
public class utility
{
 public static boolean isFutureUpdate;
}
============================================

Apex Class 2 :
============================================
public class FutureMethods
{
  @future
 public static void processLargeAccounts(set<Id> accIds)
 {
  List<Account> accToUpdate = new List<Account>();
/* isFutureUpdate is set to turn to avoid recurssion */
  utility.isFutureUpdate = true;
  update accToUpdate;
 }
}
============================================

Trigger :
============================================
trigger updateSomething on Account(after insert, after update)
{
 /*This trigger performs its logic when the call is not from @future*/
 if(utility.isFutureUpdate != true)
    {
        set<Id> idsToProcess = new Set<Id>();
        for(Account acc : trigger.new)
        {
            if(acc.NumberofEmployers > 500)
            {
                 idsToprocess.add(acc.Id);                    
            }
        }
        /* Sending Ids to @future method for processing*/
        FutureMethods.processLargeAccounts(idsToprocess);
    }
  }
} 
============================================

In the above scenario, it will first check utility.isFutureUpdate != true from utility class. If it is false that means, a call is not from the future method then it will perform its logic.

Then it will send its Ids to the FutureMethods class to process further.

For more scenarios and error problems please visit :
https://www.salesforcekid.com/2019/07/recursive-triggers-in-salesforce.html

I hope this will help you to solve your problem.
HAPPY LEARNING ☁️⚡️

AJINKYA DHAS ☁️⚡️
Salesforcekid   (http://www.salesforcekid.com)
{tushar-sharma}{tushar-sharma}
Hi,
We have multiple ways to avoid recursive triggers. They all depend on your use case, While one solution may work but will not work for others. Check the below links, It has multiple ways to avoid recursive trigger: https://newstechnologystuff.com/2020/05/28/avoid-recursive-trigger-in-salesforce/

Many Developers face recursive trigger or recursive update trigger. For example in 'after update' trigger, the Developer is performing update operation, and this leads to the recursive call. Or if we have WF field update sometimes they also contribute to recursive triggers.