2

enter image description here

In the attached debug screenshot, you can see that - according to the CODE_UNIT_STARTED and FINISHED lines, the execution seems to be going like this:

  • Record A is inserted
  • CODE_UNIT_STARTED: AfterUpdate on Record A
  • CODE_UNIT_FINISHED: AfterUpdate on Record A
  • CODE_UNIT_STARTED: AfterUpdate on Record A
  • CODE_UNIT_FINISHED: AfterUpdate on Record A
  • CODE_UNIT_STARTED: AfterInsert on Record A
  • CODE_UNIT_FINISHED: AfterInsert on Record A

According to the timestamps in the debug screenshot, the AfterInsert is the last piece to both start AND finish.

I'm aware of the pattern for non-reentrant triggers to avoid recursion, but I almost wonder if that's even what's going on here; If this were strictly a trigger recursion issue, wouldn't the AfterInsert Code Unit Started be the first thing in the debug output w/ the AfterInsert Code Unit Finished being the last? Obviously the code is executing multiple times, but I believe that is a separate thing.

1
  • does your before insert trigger on the object do DML on the same object? For example, by not recognizing that changes to trigger.new implicitly update the object and no DML is required
    – cropredy
    Commented Feb 5, 2016 at 21:09

2 Answers 2

1

Posting the answer in case anyone else comes across something similar:

we've an after insert trigger on one of the objects that is auto-submitting it to an Approval Process. It's this that is both causing another trigger on the same object to fire more than once, as well as out of order (Update first, Insert second)

0

Best way to solve this is to stop all afterinsert triggers and simply insert a record and try updating the record. Now check what all components are getting called on AfterUpdate. Then you can potentially have an answer where things could go in loops.

Also if you have too many WorkFlow with Fields Updates that could cause to re-fire as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .