before-vs-after-trigger

You are helping the user pick the right trigger phase. Triggers can fire before insert/update/delete or after insert/update/delete (or after undelete); the choice shapes performance, governor-limit usage, and what's even possible.

Decision questions

1. What does the logic do? Set field values on the record itself / create or update other records / send notifications / cascade DML / call out to external?
2. Does it need the record's Id? (Available only after insert, not before insert)
3. Does it need the old value of a field? (Trigger.oldMap available in before update and after update)
4. Does it need to fail/abort the operation? (addError available in before only — after can throw but you've already done DML elsewhere)
5. Does it touch external systems? (Callouts forbidden in triggers; queue from after)

Decision tree

Set field values on the same record being saved
  → before insert / before update — modify Trigger.new directly; no extra DML

Reject / abort the save with a user-friendly error
  → before insert / before update — addError on the record

Cascade-create child records (Order_Item__c when Order__c is inserted)
  → after insert — child records need parent's Id

Update related parent / sibling records (set Account.Total when Opportunity inserts)
  → after insert / after update — DML on related records

Recompute a roll-up that lives in another object
  → after insert / after update / after delete — DML on the other object

Publish a Platform Event
  → after insert / after update — publish-after-commit ensures event matches persisted state

Enqueue a Queueable for async work (callouts, heavy processing)
  → after insert / after update — record is committed; the queueable can rely on Id and current state

Validation that depends on other records (cross-record check)
  → before insert / before update — fetch related records and addError as needed

Output

# Trigger Phase Choice

## Description
Cascade-create three Order_Item__c records when an Order__c with Status__c='AutoLine' is inserted

## Answers
- Logic:           create child records
- Needs Id:        yes (Order__c.Id is the FK on Order_Item__c)
- Needs oldMap:    no
- Aborts save:     no
- External call:   no

## Recommendation: **after insert**

### Why
- Child records reference `Order__c.Id`, which only exists after the parent is persisted (`after insert`)
- No abort path — pure cascade
- DML cost: 1 INSERT per Order__c trigger context (200 rows = 1 bulk insert), within governor limits

### Patterns referenced
- SF-7 (Trigger Handler Framework) — `afterInsert()` method on the handler

### Boilerplate
```apex
public class OrderTriggerHandler implements ITriggerHandler {
    public void afterInsert() {
        List<Order_Item__c> items = new List<Order_Item__c>();
        for (Order__c o : (List<Order__c>) Trigger.new) {
            if (o.Status__c == 'AutoLine') {
                items.add(new Order_Item__c(Order__c = o.Id, Quantity__c = 1));
                items.add(new Order_Item__c(Order__c = o.Id, Quantity__c = 2));
                items.add(new Order_Item__c(Order__c = o.Id, Quantity__c = 3));
            }
        }
        if (!items.isEmpty()) insert as user items;
    }
    // other ITriggerHandler stubs return without action
}

Alternatives

• before insert would not work — you can't set Order_Item__c.Order__c = new Order__c().Id before the parent has an Id

## Rules

- **`before` for self-record changes; `after` for cross-record DML.** This single rule covers ~90% of cases
- **`before insert` has no `Id` and no `oldMap`.** Don't recommend it for anything that needs either
- **`addError` only works in `before`.** If the goal is to reject, `before` is the only choice
- **Don't put callouts in triggers.** Trigger phase is irrelevant — callouts inside a trigger throw `CalloutException`. Always queue them