You need to sign in to do that
Don't have an account?
Steve Berley [Left Propeller]
Preventing trigger recursion when updating related records on the same object
Let’s say you’re helping someone run the errands of daily life. A trip may contain the following segments…each is its own record in an object that are all children of an umbrella trip object
Let’s say #3 changes because you have to go to a different drug store, then #4 will also need updating since its origin changed.
Typically, you’d update #3 using a before trigger. No problem. The trigger’s scope is naturally limited to the updated record (#3) and doesn’t include #4 which also needs updating since its origin changed. As you’d expect, doing all of the updates in an after trigger causes trigger recursion.
Here’re the questions…
Note: I've left out the code since issue is more about patterns and coding strategy.
Thanks for your help…
- pick them up
- go to the doctor
- stop at the drug store
- get groceries
- return them home
Let’s say #3 changes because you have to go to a different drug store, then #4 will also need updating since its origin changed.
Typically, you’d update #3 using a before trigger. No problem. The trigger’s scope is naturally limited to the updated record (#3) and doesn’t include #4 which also needs updating since its origin changed. As you’d expect, doing all of the updates in an after trigger causes trigger recursion.
Here’re the questions…
- How do I structure my trigger so it updates the changed record and related records without causing trigger recursion?
- Is it possible to expand the scope of the before trigger to include the related records?
Note: I've left out the code since issue is more about patterns and coding strategy.
Thanks for your help…
So you would need to be thorough by checking if the field actually needs to be updated. In my above example I check if the Marketing Preference was changed.
Then in the handler before I update the actual data:
Hopefully this makes sense, and you're able to apply it to your situation. If you want to post code we could give you more specific solutions.
I have used this trick (and that seems to work): Avoid Recursive Trigger Calls
https://help.salesforce.com/articleView?id=000133752&language=en_US&type=1
The problem is when you modify many segments for the same trip with a batch process (not tested) but the static function checkRecursive works for individual change from the screen (I have got the recursive depth error without it).
Here’s what I did.
I had been setting/clearing status bits but saving them to the segment records was exacerbating the problem. Using Matt’s advice I’m now assessing status dynamically so I’m preventing trips through the trigger.
Using Alain’s checkRecursive trick I’m able to both control the number of trips through the trigger for the updated record and expand the scope so the related records also avoid trigger recursion; without a trigger execution counter.
Thank you!
Trigger:
Handler:
Note: This code was slimmed for presentation so please don't take it as fully functional....