Best use of After Update Trigger and Before Update

Question

Please read my post before marking as duplicate or irrelevant. :pray:

I have a scenario where I want to update the associated Asset record on Status update. I have implemented this scenario using After Update trigger and it is working as expected.

But my senior has different views in my PR review. We are already using Before Update(for different requirement) so he is asking to move my code to Before Update and try avoiding additional trigger context. I tried making so many points why we should not use Before Update in case of updating associated records but he is not approving my PR and asking me for the proofs why After Update is better than Before.

There is nothing much in code so I am not sharing as it wont be helpful in this case.

I gave few reasons to use After Update but he is not convienced. Can someone help me with some solid reason to use After Update

• Related Records should always update on After update trigger context as current record is saved to Database and we are sure about the field values.
• Incase of any error, we can avoid the entire execution. (He told me that chances of errors are very less and we should not bother about this scenario).
• Before trigger logic will delay the update process.
• In case of after trigger exceptions can be easily managed and don't consume time.

I know asking this kind of questions are ridiculous and silly. But I am really frustrated and for very small and easy requirement I stuck for the last few days.

Answer 1

In some cases, using before update to update related records can be problematic, because if those records then try to recursively update the original records, you'll end up with an error you wouldn't get with an after update trigger; for example, it's entirely possible for a child to update its parent, which in turn updates its children (and then the recursion ends). This is only possible with after update triggers.

In general, the two rules are:

Use before DML triggers to update the records that are currently being committed to the database, creating any new parent records that should be associated to the current record, as well as any validations that can be performed.

Use after DML triggers to create child records, update parent or child records related to the records that are currently being committed, any asynchronous code you want to queue, and any validations that can't be done in a before DML trigger (these are rare, but do exist, such as those involving rollup summary fields or formulas).

Here's a sample of reasons why these rules are in place:

• Validations in before DML operations reduce CPU time used.
• Creating parents in before DML operations allows linking the child immediately without recursion.
• Updating a parent record in a before DML trigger risks a recursive operation resulting in a "record already in update" DML exception, and also prevents the parent from querying the child records' new values, as they are not yet saved to the database.
• Records should never query child records in a after DML insert trigger, as there will never be any child records to query.
• Placing asynchronous code calls in after DML triggers reduces CPU usage when a validation rule or logic would block the update.

Salesforce is an extremely complicated system, and failure to think about the Order of Operations or what would happen in certain scenarios (examples of which provided above) can lead to unexpected surprises. Ultimately, it appears your senior has not considered the consequences of what they're asking for. Seniority does not, unfortunately, always equal experience. I recommend that you suggest they read these answers, and consult veteran experts for a second opinion.

Answer 2

IMHO the first two of your cited reasons are spot on. Your senior dev's brush off of "chance of errors are very [low]" is entirely naive - simple addition of validation rules by admins could easily bork your DML operation (validation is done between before and after), and the introduction of process builders and flows doubly so.

If you don't follow Salesforce best practice you could easily fall foul of order of execution gotchas, especially around the re-entrancy of the "save procedure" (see step 14 in the order of execution). Whatever you do you need to consider how you protect your trigger processing against such re-entrancy (this does actually mean you cannot be 100% sure of the state of the record in after update either, but that's a different story).

Answer 3

Your points are spot on! I think you should ask him what is the rational to move the code to Before Update,

1. feels like he is acknowledging the bad design but neglecting since there are less chances of DML issue.
2. Just because logic is written in Before trigger doesn't mean all logics have to be written in Before trigger.

Answer 4

asking me for the proofs why After Update is better than Before

In your case that needs to update the associated records, if done in the After, when the associated records are updated, within their trigger context it can obtain the accurate (and the latest) info of the originating records (including their change history) from the database. This latest database info is often important when the associated records need to have further logic based on it. If done in the Before, it has no way to obtain that latest info as nothing has been saved to database yet. Therefore, the After Update is better in this case.

The standpoint is that one type is only better than the other when it suits the business problem better.