Timeline for Order of execution managed vs. non-managed code
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 23, 2013 at 0:03 | comment | added | kibitzer | Speaking of which - it looks like there may have been a change in Winter 14 - I'm definitely seeing managed package triggers happening after unmanaged with this release. | |
| Sep 17, 2013 at 22:46 | vote | accept | Mark Pond | ||
| Sep 16, 2013 at 23:08 | comment | added | kibitzer | Even if the current implementation always does call managed package triggers first, I certainly wouldn't design based on that assumption. Since it isn't documented, SFDC could change it at any time. | |
| Sep 16, 2013 at 19:56 | comment | added | zachelrath | I agree with Jonathan, in my experience, the order of execution of triggers of the same type is not consistent / is undefined / is not guaranteed to be in any particular order. | |
| Sep 16, 2013 at 19:52 | comment | added | Chris Duncombe | I think we all agree that the order is undefined. The question at hand here is whether it is just a huge coincidence that managed triggers always seem to fire prior to unmanaged triggers. I find it hard to believe that it is coincidence as it always seems to be the case. | |
| Sep 16, 2013 at 19:48 | comment | added | Jonathan Hersh | Indeed, but I'd still be uncomfortable assuming that managed triggers will always fire before unmanaged. | |
| Sep 16, 2013 at 19:46 | history | edited | Jonathan Hersh | CC BY-SA 3.0 |
added 454 characters in body
|
| Sep 16, 2013 at 19:45 | comment | added | Mark Pond | I concur that the order in which things are executed is non-deterministic but it appears that there is always some order happening here... managed code is executed first, unmanaged second. Then within these two types of code, the order is not guaranteed. | |
| Sep 16, 2013 at 19:41 | comment | added | Jonathan Hersh | I'm not saying it is avoidable. I'm saying in that kind of situation, the firing order is undefined. | |
| Sep 16, 2013 at 19:40 | comment | added | Chris Duncombe | If you have a managed package that has triggers, you obviously can't help but have multiple triggers on the same object if you have your own triggers on the same object. There's no way to avoid that. | |
| Sep 16, 2013 at 19:38 | history | answered | Jonathan Hersh | CC BY-SA 3.0 |