You are here:
How Flows Run in Transactions
Flows run within transactions that group operations as a single unit. When any operation fails, the entire transaction rolls back to maintain data integrity. This includes Apex triggers, escalation rules, and all flow interviews in the transaction.
In each transaction, Salesforce enforces governor limits to prevent shared resources from being depleted. Because multiple Salesforce organizations share resources, Salesforce prevents one organization from depleting all the resources and leaving the other organizations high and dry. It’s similar to an apartment building that uses one cache of water to service every tenant. If your neighbor uses all the water, you can’t take a shower. (It’s trite, but hopefully you get the idea.) Per-transaction governor limits help prevent such things from happening.
Starting from Winter ’26, you can configure all flow types to determine at run time whether a new transaction is required to successfully execute the action. Previously, only screen flows had transaction control. For record-triggered flows, you can apply transaction control to actions in an asynchronous or scheduled path but not in a path to run immediately.
| If the action was configured in | Default action behavior is |
|---|---|
| Winter ‘26 or later | Let the flow decide (recommended) |
| Summer ‘25 or earlier | Always continue in current transaction |
The transaction control option is available for the action under the Advanced setting for all custom actions, and for standard actions only if they perform a callout.
Settings Description
Configure actions to automatically let the flow determine at run time whether a new transaction is required to successfully execute the action.
| Settings | Description |
|---|---|
| Let the flow decide (recommended) | The flow determines at run time whether a new transaction is required to successfully execute the action. If this action involves a callout, and the current transaction has pending operations, the current transaction is committed before executing the action in a new transaction. When debugging the flow, the action always executes in the current transaction and can cause an error if there are callouts. |
| Always start a new transaction | Before this action is executed, the current transaction is committed. The action is then executed in a new transaction. If the action fails for some reason, Salesforce can’t roll back any operations from the previous transaction. Debug runs are unsupported. |
| Always continue in current transaction | This action is always executed in the current transaction. If the action involves a callout while the current transaction has pending operations, the flow fails. |
- How a Transaction Starts
Depending on how the flow was distributed, a transaction that runs an interview for that flow starts in different ways. - How a Transaction Ends
When a transaction ends depends on whether the flow contains certain elements and whether it originally started because a record was changed.
How a Transaction Starts
Depending on how the flow was distributed, a transaction that runs an interview for that flow starts in different ways.
| Distribution Method | Transaction starts when... |
|---|---|
| Process Builder1 | A record is created or updated. |
| Flow URL | The URL is accessed. |
| Custom button or link | The button or link is clicked. |
| Visualforce page | The page is accessed. |
Interview.start() method |
If the method starts via a Otherwise, the transaction starts when the method (or a parent method) is invoked. The |
| REST API (Custom Actions or Flows resource) | When the REST call is made. Depending on how the REST call is implemented, the limits can be shared with other operations. |
1The same also applies if the flow is distributed through a workflow rule. The pilot program for flow trigger workflow actions is closed. If you've already enabled the pilot in your org, you can continue to create and edit flow trigger workflow actions. If you didn't enable the pilot in your org, use Flow Builder to create a record-triggered flow, or use Process Builder to launch a flow from a process.
How a Transaction Ends
When a transaction ends depends on whether the flow contains certain elements and whether it originally started because a record was changed.
The transaction ends when:
- A Screen, Local Action, or Wait element is executed
- The order of execution has completed—if the flow was triggered when a record was created or updated
- All the interviews in the transaction have finished
If the interview is one of many things being done in a given transaction, that interview shares the transaction’s governor limits with the other operations.
You update 100 cases through Data Loader. Due to the order of execution in a transaction and the customizations in your organization, here’s what happens.
| STEP | Transaction Operation | DML Statement Used | SOQL Query Used |
|---|---|---|---|
| 1 | Cases are saved to the database, but aren’t committed yet. | No | No |
| 2 | Case assignment rules are executed. Each case’s owner is updated. | Yes | No |
| 3 | Case escalation rules are executed. If any case has been open for 10 days, an email is sent to the owner. | No | No |
| 4 | Process is started. | No | No |
| 5 | Process looks up the case’s account. | No | Yes |
| 6 | If the account is hot, process uses Chatter to notify the account owner that there’s a new case associated with the account. | Yes | No |
| 7 | Process launches a flow interview. | No | No |
| 8 | Flow interview looks up the parent account and how many cases it has. | No | Yes |
| 9 | Flow interview checks whether the account has more than five open cases. | No | No |
| 10 | If it does, flow interview looks up the account’s division manager then posts on the account’s Chatter feed to notify the division manager and account owner. | Yes | Yes |
| 11 | If it doesn’t, flow interview posts on the account’s Chatter feed to notify only the account owner. | Yes | No |
