Order of Execution

Module 19's "What Really Happens When You Insert a Record" lesson introduced a simplified 6-step sequence: system validation, before triggers, custom validation rules, the save, after triggers, other automation. Everything in this module — before/after timing, Trigger.new, handler classes — has been building toward making that sequence concrete rather than abstract.

1. Existing record loaded from the database (for update), or a new one initialized (for insert).
2. System validation — required fields, data types.
3. before triggers run — able to freely modify Trigger.new's fields, since nothing is saved yet.
4. Custom validation rules run — checked against the (possibly before-trigger-modified) values.
5. The record is saved — Id is now assigned for a new record.
6. after triggers run — can see the final saved state, including Id, but changing a field here needs a fresh update.
7. Other automation — assignment rules, workflow rules, processes.

Steps 3 and 6 are exactly this module's before/after trigger timing distinction, now placed in the full sequence alongside validation rules.

trigger AccountTrigger on Account (before insert) {
    for (Account acc : Trigger.new) {
        if (String.isBlank(acc.Industry)) {
            acc.Industry = 'Unknown';
        }
    }
}

Because before triggers (step 3) run before validation rules (step 4), a validation rule requiring Industry to be populated would actually pass for a record that started with a blank Industry — the trigger's default already filled it in by the time validation checks it. This exact ordering is why before triggers are a common, deliberate place to satisfy a validation rule automatically rather than forcing every caller to remember to set the field themselves.