How do you manage transactions and rollbacks in a Flow?

Posted by Vinay Vernekar 11th November 2025

Overview

Salesforce Flows execute within Salesforce transactions. If an unhandled error occurs in a running transaction (for example, a DML exception), Salesforce rolls back all changes made in that transaction. Understanding how Flow transaction boundaries work and how to design for error handling, partial commits, and safe rollbacks is essential for building reliable automations.

Key Concepts

Keep these fundamentals in mind:

  • Flows executed synchronously run in the same transaction as their caller. An unhandled exception rolls back the entire transaction.
  • Before-save (record-triggered) flows execute before the record is committed and are optimized for field updates; they do not perform DML separately.
  • After-save (record-triggered) flows run after the initial save but still participate in the same transaction unless you explicitly decouple work.
  • Wait (Pause) elements, asynchronous Apex (Queueable/Future/Batch), and Platform Events create separate transactions and can be used to isolate DML so that failures don’t roll back the original transaction.

Strategies to Manage Transactions and Rollbacks in Flow

1) Use Fault Paths and Graceful Error Handling

Every element that performs external operations or DML supports a Fault connector. Configure Fault paths to catch exceptions, log them (to a custom object), show friendly user messages, or perform compensating actions instead of letting the exception bubble up and cause a full rollback.

2) Decouple Work into Separate Transactions

If you need to ensure the main Flow’s work isn’t rolled back when a downstream operation fails, run that work in a separate transaction using one of these approaches:

  • Wait (Pause) element — Pausing the Flow causes the current transaction to complete; subsequent resume runs in a new transaction.
  • Platform Events — Publish a platform event from the Flow; subscribers (triggered processes or Apex) handle the heavy/fragile DML asynchronously.
  • Queueable / @future Apex — Call an invocable Apex that enqueues a Queueable job or uses @future to perform DML in a separate transaction.

3) Use Invocable Apex for Complex Transaction Control (Carefully)

Invocable Apex can be used to handle advanced needs. Two important patterns:

  • Use asynchronous Apex (Queueable/@future) called from Flow to perform DML outside the Flow’s transaction.
  • You can set a Savepoint and rollback in Apex via Database.setSavepoint() and Database.rollback(savepoint), but remember savepoints apply to the entire current transaction. Using savepoints from Apex that’s called synchronously from a Flow can impact Flow changes—so use this only when you fully control all DML in that transaction.

// Example: simple invocable Apex that runs asynchronously (Queueable)
public class FlowQueueableInvoker {
@InvocableMethod(label='Enqueue Async DML')
public static void enqueueJobs(List recordIds) {
System.enqueueJob(new AsyncDmlJob(recordIds));
}

public class AsyncDmlJob implements Queueable {
private List ids;
public AsyncDmlJob(List ids) {
this.ids = ids;
}
public void execute(QueueableContext ctx) {
// DML performed here is in a separate transaction
// handle exceptions and retries as needed
}
}
}

4) Design Compensating Actions

Sometimes you can’t avoid a failure that partially changes data. Design flows to record state and allow compensating actions (for example, reversing a set of changes via a second Flow/Apex call) rather than relying on implicit rollback.

5) Prefer Declarative Options When Possible

For record updates that don’t need complex transaction control, use before-save record-triggered flows to avoid extra DML and improve performance. If you must run DML on related records, consider after-save flows combined with asynchronous processing for risky operations.

Practical Examples & Recommendations

Recommendations you can apply today:

  • Always add Fault paths to elements that do DML, call external services, or invoke Apex.
  • For operations where failure must not rollback the main transaction (e.g., sending notifications, heavy integrations), move that work to Platform Events or Queueable Apex.
  • Use Wait elements strategically to split long-running or error-prone work into separate transactions.
  • If you use Apex savepoints/rollbacks, document and test thoroughly—savepoints affect the entire transaction, including Flow changes.

Summary

Flows run inside transactions; unhandled errors roll back changes. Use Fault paths, asynchronous patterns (Wait, Platform Events, Queueable/@future Apex), and careful invocable Apex design to control transactional behavior. When in doubt, decouple risky DML into a separate transaction so failures don’t undo your primary work.

Tags: