Order of Execution, Transactions, Savepoints, Partial Success & Locking in Salesforce

Salesforce follows a strict, predictable process when saving data. Each step is carefully designed to ensure that operations either succeed completely or fail safely—without leaving your data corrupted.

These core concepts—Order of Execution, Transactions, Locking, Savepoints, and Partial Success—form the foundation for reliable automation and error handling. Together, they give developers precise control over how data changes are applied and recovered.

Order of Execution

When you click Save in Salesforce, the platform doesn’t just write data instantly. Instead, it runs through a well-defined series of operations known as the Order of Execution.

Understanding this order is critical for debugging unexpected behavior and building dependable automations.

Core Concept:

A consistent, rule-based checklist that Salesforce executes—step by step—every single time a record is saved.

Simplified Flow:

1. Before Triggers:
   Executes before the record is saved to the database.
   ? Used to validate, clean up, or modify field values before saving.

2. System Validation:
   Standard and custom validation rules are checked.
   ? If any rule fails, the process stops immediately—no data is saved.

3. Database Save:
   The record is written to the database but not yet committed.
   ? This allows for rollbacks if later steps fail.

4. After Triggers:
   Executes after the record has been saved.
   ? Often used to update related records (for example, parent or child objects).

5. Post-Save Automation:
   Includes Workflow Rules, Process Builder actions, and record-triggered Flows.
   ? These automations handle additional logic after the record is saved.

6. Commit:
   Salesforce permanently writes all changes to the database.
   ? If any step above fails, all prior operations are rolled back to maintain data integrity.

By following this sequence, Salesforce ensures your data remains consistent, even if something goes wrong halfway through.

Transactions & Locking

A transaction is a sequence of operations that Salesforce treats as a single logical unit of work. If one step fails, the whole transaction rolls back—preventing incomplete or inconsistent data.

Core Concept (Transaction):

“All or nothing.” Either every action in the transaction succeeds and is saved (committed), or every action fails and is undone (rolled back).

This guarantees data integrity, especially when multiple records or objects are being updated at once.

Core Concept (Locking):

When Salesforce starts editing a record inside a transaction, it automatically locks that record to prevent other transactions from changing it simultaneously.

? Other users or processes attempting to edit the same record must wait until the lock is released.

This mechanism prevents race conditions, where multiple edits could overwrite each other, ensuring reliable and conflict-free updates.

Savepoints & Partial Success

Not every operation needs to be “all or nothing.” Salesforce provides savepoints and partial success features to help developers manage bulk operations more efficiently.

Core Concept (Savepoint):

A savepoint acts like a checkpoint or bookmark in your transaction.

? If a later part of your code fails, you can roll back to this specific point—without undoing everything that came before.

This is extremely useful in complex operations with multiple DML (Data Manipulation Language) statements.

Core Concept (Partial Success):

When working with large datasets (for example, inserting 100 contacts), Salesforce allows you to process records in batches.

? If one batch fails, you can roll back to the previous savepoint and continue with the next batch.
? This way, valid records are still saved while the failed ones are skipped.

It’s a flexible way to handle large-scale data processing without losing successful work due to a single error.

Code Example: Using Savepoints

Here’s a simple example that demonstrates how savepoints work in Apex:

// List of contacts to insert
List<Contact> contactsToInsert = new List<Contact>{
    new Contact(FirstName='Jane', LastName='Doe'), // This one is valid
    new Contact(FirstName='John') // This one is invalid (missing LastName)
};

// Set a "bookmark" before we try the risky operation
Savepoint sp = Database.setSavepoint();

try {
    // Attempt to insert the list of contacts. This will fail.
    Database.insert(contactsToInsert, false); // The 'false' allows partial success
} catch (DmlException e) {
    // An error occurred! Roll back to the savepoint.
    // This undoes the failed DML operation but keeps anything before the savepoint.
    Database.rollback(sp);
    System.debug('Operation failed and rolled back. Error: ' + e.getMessage());
    // You could add logic here to retry, log the error, etc.
}

Sample Interview Questions

Question 1:

A user saves a record, and a field value is unexpectedly being cleared. Where would you look first to debug this?
Answer: Start by checking Before Triggers and record-triggered Flows that run before save, since they can programmatically alter field values before the record is committed.

Question 2:

Can you explain what a transaction is in your own words? Why is it important?
Answer: A transaction is a single unit of work that must complete fully or not at all. It’s crucial for maintaining data integrity.
For example, during a bank transfer, both the withdrawal and deposit must succeed together—you can’t have one without the other.

Question 3:

When would you use a savepoint? Describe a business scenario.
Answer: Use a savepoint when performing multiple DML operations in one transaction where a part might fail.
For example, while processing a large data import, set a savepoint before each batch.
If batch #5 fails, roll back to the previous savepoint and continue with batch #6—so the first four batches remain successfully committed.

Question 4:

What’s the difference between insert records; and Database.insert(records, false);?
Answer:

• insert records; → All-or-nothing operation. If one record fails, the entire transaction rolls back.

• Database.insert(records, false); → Allows partial success. If one record fails, others still get inserted successfully.

Final Thoughts

These Salesforce mechanisms—Order of Execution, Transactions, Locking, Savepoints, and Partial Success—are what make the platform both powerful and dependable.

They ensure every change happens in a controlled, predictable way and allow developers to recover gracefully from errors.
Understanding them means fewer surprises, cleaner automation, and safer data—exactly what every Salesforce professional aims for.