Considerations for Orchestrations

Entry and Exit Condition Requirements

Resources selected for a requirement for a step entry condition or a stage or step exit condition can contain orchestration resources or global variables. There are limitations for what can be included in a requirement.

• To use a record for the Resource or Value fields, you must select a field on the record.
• The referenced record must use fields from its object, not fields from a related record.

Record-Change-Triggered Flow Orchestration Events

A requirement for a step entry condition or a stage or step exit condition can contain a reference to a record. Changes to that record can trigger the orchestration to evaluate the status of the current stage and the outstanding steps within it. There are limitations for when the record can trigger condition evaluations.

• The referenced record’s parent object must support change events.
• The referenced record fields aren’t IsDeleted, SystemModeStamp, or any field that’s derived from a related record or a formula.
• The referenced record is null or has an invalid ID.
• The referenced record is a global variable in an autolaunched orchestration.
• The referenced record is a global variable other than $Record in a record-triggered orchestration.

Input Values for Flows

If the combined input values for a flow called by an orchestration step is more than 32,768 characters, the orchestration fails. This error can be caused by passing one or more records to a flow called by a step. To avoid this error, pass a record ID to the referenced flow, and use a Get Records element in the flow with the passed ID. Using a passed ID with a Get Records element also means that you always have the latest version of the record.

If the combined input values for a flow called by a flow approval process step is more than 32,768 characters, the flow approval process fails. This error can be caused by passing one or more records to a flow called by a step. To avoid this error, pass a record ID to the referenced flow, and use a Get Records element in the flow with the passed ID. Using a passed ID with a Get Records element also means that you always have the latest version of the record.

Email Notifications

When a flow called by a step fails and causes an orchestration to fail, two email notifications are sent.

• A flow error notification
• An orchestration error notification

Governor Limits and Concurrent Orchestration Step Execution

When flow orchestration executes steps in bulk, it groups concurrent interviews into batches by user context and flow version. Interviews with different user contexts or flow versions run in separate groups. Groups run in order but within the same transaction.

Flow orchestration bulkifies step execution in several situations, including:

• Multiple users complete work items at the same time
• A bulk record update triggers multiple orchestration runs
• A record change event resumes multiple orchestration runs

All groups in a batch run in one transaction and share governor limits. SOQL queries, DML statements, and Apex CPU time accumulate across all groups. Record-triggered flows and Apex triggers that run when a flow that a step calls creates, updates, or deletes a record count against the same limits.

Flow orchestration groups interviews based on which interviews are in the processing queue at the moment of execution, not on when users start. Staggering execution times doesn't reliably reduce batch sizes.

SOQL 101 and Apex CPU limit errors most commonly result from one of these causes.

• SOQL queries, DML, or callouts inside loops in the flow that a step calls
• Cascading automation in the same transaction, such as record-triggered flows or Apex triggers that run when the flow that a step calls creates, updates, or deletes a record
• A flow that a step calls with many sequential operations and no transaction boundary to reset governor limits

To avoid approaching governor limits, follow these design practices.

• Keep SOQL queries, DML, and callouts out of loops so that the flow bulkifies them automatically.
• For invocable Apex actions that a step calls, use collection parameters (List<RequestType>, List<ResponseType>) and perform DML on the full collection, not inside a loop.
• Put callouts and DML operations in separate steps, each of which runs in its own transaction that resets governor limits.
• Add a wait element to the background step's autolaunched flow. A wait element forces the step to execute asynchronously in a separate transaction.