Transactions, Order of Execution and Recursion

What it is

A transaction is a set of operations that succeed or fail together. When a record is saved, Salesforce runs a fixed sequence of steps, the save order of execution: flows, triggers, validation, more automation, roll-ups, then the commit.

If any step throws an unhandled error, everything in the transaction rolls back. Updates made by automation can also cascade into other saves and fire triggers again, which is where recursion comes from.

How it works

The save order (simplified)

Three facts appear in many questions:

• Before-save flows run before before triggers. A trigger sees, and can change, a value set by a before-save flow.
• Validation rules run after before triggers. A trigger can make a record fail validation, or fix it so it passes.
• Asynchronous work starts only after commit. If the transaction rolls back, the future call or queued job never runs.

Example: who wins?

A before-save flow sets Priority__c to Medium when it is blank. A before insert trigger changes Medium to Low. A validation rule fails when Priority is Low and Amount is over 1,000. A user saves a record with blank Priority and Amount 2,000.

Flow sets Medium, the trigger sets Low, and the validation rule then fails the save. The order decides the outcome.

Recursion

An after update trigger on Account updates Contacts, and a Contact trigger updates the Account again: the triggers call each other. Salesforce stops a chain at a trigger depth of 16 with an error, but a loop usually needs fixing long before that.

public class AccountTriggerHandler {
    private static Set<Id> processed = new Set<Id>();
    public static void afterUpdate(List<Account> accs) {
        List<Account> toDo = new List<Account>();
        for (Account a : accs) {
            if (!processed.contains(a.Id)) {
                processed.add(a.Id);
                toDo.add(a);
            }
        }
        // work only on toDo
    }
}

Track processed record Ids in a static Set rather than using a single static Boolean. A Boolean that is set after the first chunk of 200 records skips every later chunk of the same transaction, so records 201 and above are never processed.

Savepoints and rollback

Savepoint sp = Database.setSavepoint();
try {
    insert ord;
    insert lines;
} catch (DmlException e) {
    Database.rollback(sp);
    throw new OrderException('Order not saved: ' + e.getMessage());
}

Database.rollback(sp) undoes DML since the savepoint. Each savepoint and rollback counts against the DML statement limit.

A worked example

An after insert trigger on Account issues 1 query, then inserts 2 Contacts per account in one DML statement. The Contact before insert trigger runs 2 queries per run. A user inserts 200 accounts in one statement.

The Account trigger uses 1 query. The 400 contacts are processed in two chunks of 200, so the Contact trigger runs twice: 4 queries. The transaction uses 5 queries, and every step shares those limits.

How the exam asks about this

• "Does a before trigger see the value a before-save flow set?" Yes, flows run first.
• "Which runs first, validation rules or before triggers?" Before triggers.
• "Why are only the first 200 records processed?" A static Boolean recursion guard.