Apex Savepoint And Rollback

Apex Savepoint and Rollback

Activate when multi-step DML needs a safety net: if a later step fails, earlier steps should be undone. Database.Savepoint + Database.rollback(sp) is Salesforce's mechanism. The semantics are subtle: IDs on in-memory records are NOT reset, governor limits are not fully reset, and rollback after a callout is forbidden.

Before Starting

• Place the savepoint BEFORE the first DML you might want to undo.
• Never call Database.rollback after an HTTP callout in the same transaction. Platform prevents it.
• Clear Id fields manually after rollback on in-memory records you intend to re-insert.

Core Concepts

The savepoint lifecycle

Savepoint sp = Database.setSavepoint();
try {
    insert accounts;
    insert contacts;
    insert opportunities;
} catch (Exception e) {
    Database.rollback(sp);
    // handle
}

setSavepoint() snapshots the transaction; rollback(sp) undoes DML after the savepoint.

What rollback undoes

• DML (insert/update/delete/upsert) after the savepoint
• Change to records' database state

What rollback does NOT undo

• IDs populated on in-memory SObject instances (you must null them if re-inserting)
• Emails sent via Messaging.sendEmail
• HTTP callouts (and you can't even call rollback post-callout)
• Static variable state
• Governor limit counters are partially reset (DML rows yes; SOQL queries no)

Nested savepoints

Valid; each call to setSavepoint() creates a new savepoint. Rolling back an outer savepoint invalidates inner ones.

Limits

Database.setSavepoint counts against the 150 DML-statement limit. Database.rollback also counts. Avoid savepoint-per-record loops.

Common Patterns

Pattern: All-or-nothing multi-DML

Savepoint sp = Database.setSavepoint();
try {
    insert parents;
    insert children;  // if this fails, parents rolled back too
} catch (DmlException e) {
    Database.rollback(sp);
    throw new MyException('Operation aborted', e);
}

Pattern: Rollback-then-rethrow with clean IDs

Savepoint sp = Database.setSavepoint();
try {
    insert accs;
    insert opps;
} catch (Exception e) {
    Database.rollback(sp);
    for (Account a : accs) a.Id = null;  // so retries can re-insert
    throw e;
}

Pattern: Pre-callout DML with deferred rollback decision

Rollback must happen before any callout. If you need conditional rollback based on callout response, do DML AFTER the callout, or don't use savepoints at all — use a compensating action.

Decision Guidance

Recommended Workflow

1. Identify the transaction boundary — where savepoint belongs.
2. Place Database.setSavepoint() before the first reversible DML.
3. Wrap remaining DML in try/catch; rollback in catch.
4. Null out IDs on in-memory records if retry is planned.
5. Verify NO callouts occur between savepoint and rollback.
6. Count savepoint + rollback against DML limit (each costs 1).
7. Test failure paths with forced exceptions to confirm rollback works.

Review Checklist

• Savepoint placed before reversible DML
• No HTTP callouts between savepoint and rollback
• Rollback inside catch block, not in fall-through
• IDs nulled on in-memory records when retry expected
• No savepoint inside a loop
• Nested savepoints used sparingly and understood
• Test class with forced exception proves rollback
• Limits considered (savepoint + rollback = 2 DML statements)

Salesforce-Specific Gotchas

1. Rollback after callout throws CalloutException. Order matters: DML-savepoint-DML-rollback OR callout-then-DML, never mix.
2. IDs persist on in-memory records after rollback. Database state is undone; Apex objects still carry IDs — re-inserting throws "Id already exists" if you don't null them.
3. SOQL query count is NOT reset by rollback. Only DML row counts partially reset. A rollback loop can still blow the SOQL-101 limit.

Output Artifacts

Related Skills

• apex/apex-partial-dml — all-or-none and partial DML options
• apex/apex-exception-handling — structured error handling
• apex/apex-transaction-boundaries — service-layer transaction design