--- schema_version: "1" id: 6ee2e727d1fcaeb520c8bb5b520abb3d157ba696c4726ebbf89dcb55c5774810 title: How Flows Run in Transactions collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/flow_concepts_transaction.md canonical_url: https://help.salesforce.com/s/articleView?id=platform.flow_concepts_transaction.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 29e1c45c213922c0f2e65e551c5298d5d44c2f49dbd97385ef293f5c436472b9 description: 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. products: - Flow Builder - Salesforce Platform release: "264" --- # 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 run 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** | ![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_tip.png) Tip For all flows, Salesforce recommends letting the flow decide to be the best way to control the transaction. For actions configured in Summer ’25 or earlier, change the transaction control to **Let the flow decide (recommended)**. 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 run the action. | Settings | Description | | --- | --- | | **Let the flow decide (recommended)** | The flow determines at run time whether a new transaction is required to successfully run the action. If this action involves a callout, and the current transaction has pending operations, the current transaction is committed before running the action in a new transaction. When debugging the flow, the action always runs in the current transaction and can cause an error if there are callouts. | | **Always start a new transaction** | Before this action runs, the current transaction is committed. The action is then run 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 run in the current transaction. If the action involves a callout while the current transaction has pending operations, the flow fails. | - **[How a Transaction Starts](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_transaction.htm&release=264.0.0&type=5)** Depending on how the flow was distributed, a transaction that runs an interview for that flow starts in different ways. - **[How a Transaction Ends](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_transaction.htm&release=264.0.0&type=5)** When a transaction ends depends on whether the flow contains certain elements and whether it originally started because a record was changed. #### See Also - [Flow Bulkification in Transactions](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_bulkification.htm&release=264.0.0&type=5 "When a flow runs for multiple records at the same time, Salesforce creates one flow interview per record. Bulkification groups similar operations when interviews for the same flow reach the same element, helping the transaction use fewer queries and statements.") - [Per-Transaction Flow Limits](https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit_transaction.htm&release=264.0.0&type=5 "Salesforce strictly enforces limits to ensure that any runaway flows don't monopolize shared resources in the multitenant environment. Per-transaction limits, which Apex enforces, govern flows. If an element causes the transaction to exceed governor limits, the system rolls back the entire transaction. The transaction rolls back even if the element has a defined fault connector path.") - [Process Limits](https://help.salesforce.com/s/articleView?id=platform.process_limits.htm&release=264.0.0&type=5 "When building processes, keep shared limits and Apex governor limits in mind. In addition, a process’s API name must be unique across all processes and flows in your Salesforce org.") ## 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 before or after trigger, the transaction starts when a record is created or updated.

Otherwise, the transaction starts when the method (or a parent method) is invoked.

The start() method shares its limits with other operations in the transaction and other methods in the class.
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. ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_note.png) Note When a Screen element, local action, or Wait element is run, the existing transaction ends and a new one begins. ## 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 run - The order in which actions run has completed—if the flow was triggered when a record was created or updated - All the interviews in the transaction have finished ![Tip](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_tip.png) Tip If you think that a flow’s interview is likely to hit governor limits within its transaction, consider adding a Screen, Local Action, or Wait element. 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. ![Example](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-platform_automation-264-0-0-production-enus/60568438-ec7e-4665-acd1-7c80dcbe60d5/images/icon_example.png) Example You update 100 cases through Data Loader. Due to the order in which they're run 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 run. Each case’s owner is updated. | Yes | No | | 3 | Case escalation rules are run. 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 | #### See Also - [_Apex Developer Guide_ : Triggers and Order of Execution](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)