What Really Happens When You Insert a Record

When insert acc; runs, Salesforce works through roughly this sequence, in order:

1. System validation — required fields, field-level data types, and basic integrity checks.
2. Before triggers — custom Apex logic that runs before the record is saved (a full Triggers module covers this soon).
3. Custom validation rules — declarative rules configured in Setup.
4. The actual save — the record is written to the database, and Id is assigned.
5. After triggers — custom Apex logic that runs after the record is saved, now with access to the final Id.
6. Other automation — assignment rules, workflow rules, and similar declarative automation.

This is a simplified version — the full, exact order of execution (with rollback behavior and more edge cases) is a well-known and more advanced Salesforce topic, revisited directly once triggers are introduced.

Account acc = new Account(Name = 'Riverbend Farms');
System.debug(acc.Id); // null — nothing saved yet

insert acc;
System.debug(acc.Id); // now populated

acc.Id only exists after step 4 in the sequence above — this is exactly why a before trigger (step 2) never has access to a record's Id on insert, while an after trigger (step 5) always does. Nothing mysterious is happening — it's a direct consequence of when each step actually runs relative to the save itself.

Almost every confusing "why did my trigger not see the field I just set" or "why is this validation rule blocking a normal update" question later in this course traces back to exactly where in this sequence a particular piece of logic ran. Having a rough mental map of the sequence now — even before triggers are formally introduced — makes those future lessons click much faster.