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
SwerzSwerz 

Recursion of triggers

Hi Guys,

 

 

I am analysing the impact of something called 'critical updates' from SFDC for my organisation. It mentions that some of our triggers might be having unnecaessary recursions. They define recursion as:

 

"A recursion is a situation in which a part of your custom logic (such as a roll-up summary field or Apex trigger) causes Salesforce to execute the logic twice when saving a record, often resulting in undesirable behavior." 

 

Do you have any idea how can I verify that a trigger is having recursion? Can I monitor it?

 

Thanks,

 

S

Richie DRichie D

Swerz,

 

One place to start could be to write some testmethods to cover your triggers and insert into the trigger some debug messages. These would then appear in the 'run test' output. You could also try using the System Log to see whats going in when certain things happen when the user does something in the UI.

 

I would have thought that your triggers would be ok until you reach you governor limits - if this hasn't occured then there's no real problem.

 

In some cases 'controlled' recursion is part of the functionality required by a system so it isn't always a no-no to have recursion per-say.

 

R. 
SatgurSatgur

Hi Swerz,

 

I would like to refer you to Spring'09 release and some key updates provided by Salesforce in relation "recursive trigger" scenarios.

 

I am providing possible scenarios below which had been identified as a sure-shot cases of potential recursion in trigger/ duplicate firing of triggers -

 

 

Suppose you have a master and child object.

   1. Master object has a trigger A (after insert, update, after undelete)

   2. Master object has a Workflow Rule R1 (which creates a Task if the condition is met)

   3. Trigger A in turn makes an update on Child object.

   4. Master Object has a ROLL UP Summary field on Child. So if step #3 (trigger) does update child, its roll up would reflect in Master.

 

What was happening as a result of above case, if when roll up field values changes on Master, it gets treated as an update to the Master and causes TRIGGER A and Workflow Rule R1 to fire again.

 

Not only above scenario, there can even be cases where you have a Trigger B, defined on Child object (after update, after delete) which in turn makes update to Master object.

 

What Salesforce did from Spring'09 onwards, that did applied some fixes in platform to detect these recursive conditions (parent updating child and child again updating parent) and includes checks to avoid firing of TRIGGER, Workflow Rule on Parent twice.

 

Now you need to verify in your Org if such cases do exist, and verify that with new fixes that Salesforce has rolled out in Spring'09 onwards, these functionalities continue to work correctly & do not malfunction.

 

You can refer to Spring'09 release documentation for details. I am providing a snapshot of the documentation below for your quick reference -

 

"if you have an Apex trigger with a trigger event of after update, after insert, after undelete, or before delete that: • Updates the current record• Updates any child record of the current record, and the current record has a roll-up summary field• Updates an unrelated object that has an Apex trigger that causes an update on the current record• Deletes the current record or updates an unrelated object that has an Apex trigger that deletes the current record (after update or after insert triggers only)If your organization has such customizations, read the examples to understand how your customizations might be affected and how you can correct any unintended functionality.  If your organization has such customizations, read the following examples to understand how your customizations might be affected and how you can correct any unintended functionality.

"

 

 

Regards

Satgur
SwerzSwerz

Hi Satgur,

 

thanks for the input.

 

I am actually analysing the exact same scenario for my org. Looking for such structures. But its a bit tricky, finding such processes. That's why I wanted to know if I can monitor a trigger recurring and can analyse why that is happening.

 

I guess Richie's sloution is what would do the trick. thanks Richie. Let me get back if I could get it done :).

 

thanks