Trjtdtk

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?

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 before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, 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 a before trigger)


• 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.

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.