Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?
Add a comment
|
2 Answers
If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.
Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.
Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:
- Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X
- If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a
beforetrigger (or more accurately, before theaftertrigger is run), and have related record update logic in anaftertrigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in abeforetrigger) - Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).
Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)
Conclusion:
You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.
-
Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.– sfdcfox ♦Commented Mar 21, 2019 at 13:55
-
@sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.– Derek FCommented Mar 21, 2019 at 14:11
-
1Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g.
Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.– sfdcfox ♦Commented Mar 21, 2019 at 14:15 -
Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.
As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:
trigger CreateGuid on Contact (before insert) {
ContactTriggerHelper.createGuidsForContacts(Trigger.new);
}
trigger UpdateGuidList on Contact (before insert) {
ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
}
If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.
However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.
As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.
Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.
