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.
Required Editions
| Per-Transaction Limit1 |
Value |
|
Total number of SOQL queries issued
(All executions of Get Records elements,
and executions of Update Records or Delete Records elements that use filter
conditions)
|
100 |
|
Total number of records retrieved by SOQL queries
(All executions of Get
Records elements, and executions of Update Records or Delete Records elements that
use filter conditions)
|
50,000 |
|
Total number of DML statements issued
(Create Records, Update Records, and
Delete Records executions)
|
150 |
| Total number of records processed as a result of DML statements |
10,000 |
| Maximum CPU time on the Salesforce servers |
10,000 milliseconds |
| Total number of duplicate updates allowed in one batch |
12 |
1 Autolaunched flows are part of the larger
transaction that they were launched through and share that transaction’s limits. For
example, flows launched from Apex or a process are executed with the Apex or process actions
as part of the larger transaction. Flows with Screen elements can span multiple
transactions. A new transaction begins each time the user clicks Next
in a screen. Flows with Wait elements span multiple transactions. A transaction ends when a
flow interview pauses for an event. When the flow interview resumes, a new transaction
begins. Everything after the Wait element is executed as part of a batch transaction that
includes other resumed interviews. The batch includes interviews executed by the same user
ID, have the same execution time, and have the same flow version ID.
