Distinguish Apex before-trigger and after-trigger semantics and choose the correct context for field defaulting versus cross-object writes

In-depth guide

Steps

1. Use a before-insert or before-update trigger to set or modify fields on the records in Trigger.new directly — changes here are saved without a separate DML call
2. Use an after-insert or after-update trigger when you need the system-assigned record Id (unavailable before insert) or when writing to related records via a separate DML statement
3. Never issue DML on the SObject type of the triggering records inside a before trigger — this causes a self-triggering loop and a runtime error
4. For validation that should prevent save, throw a custom exception or call record.addError() inside a before trigger; addError() in an after context still rolls back the transaction
5. When both before and after logic is needed, use a single trigger with both contexts delegating to one handler to avoid ordering ambiguity between two separate trigger files
6. Document the context choice in comments to make it clear to future maintainers why a particular context was selected