Actions run in sequence. Place a producer before the Actions that consume its output, and respect the request, response and transaction boundaries shown in the workspace.

The sequence determines execution order. There is no separate Target Order control in the Actions workflow and no drag-and-drop reordering in version 1.53.

For Outbound and Credential Payloads, HTTP Request and HTTP Response must be consecutive. Queries or other eligible preparation can run before the request. Data Targets run after the response is available.

For synchronous Inbound Payloads, HTTP Request is first and HTTP Response is last. Queries, Targets, Flows and eligible child Payloads can process the request between them, subject to callout restrictions.

For asynchronous Inbound Payloads, HTTP Request is followed immediately by HTTP Response. Remaining Actions run after the response in background processing. The early response cannot contain results that those later Actions have not produced.

For Email Handler Payloads, Email is first and the optional processing Actions are Queries and Targets. Email Response configures the final reply behaviour. Flow and child Payload Actions are not available for Email Handler Payloads.

For CSV Import Payloads, CSV Import is first. Queries, Targets, Flows and eligible child Payloads can follow it. These Actions process chunks of the file; they do not make the entire file one atomic transaction.

Values produced after the transaction boundary are unavailable to the early response.

Salesforce callout and DML rules still apply. Payload Actions must precede Data Targets because the child makes callouts. Check the work inside a Flow too: if it performs DML, a later HTTP callout can fail because the transaction has uncommitted work.

Moving a callout into a child Payload does not remove that restriction. External requests that already completed are not undone when Salesforce work rolls back.

Immediate, Queueable and Batchable have different transaction behaviour. The permitted choices depend on both the Payload type and how it is started.

The general Payloads Flow invocable runner rejects Batchable execution for Actions Payloads containing Targets or Flows. Use an appropriate supported mode for that entry point. The manual Outbound runner handles this case differently: when Batchable is selected, it limits the batch to one Job per execution scope.

CSV Import has a dedicated Queueable and Batchable runtime. Its rules are separate from that general Flow restriction and it does not support Immediate execution.

Deferred or no-commit execution generally rejects Target and Flow Actions. The generated Credential refresh sequence has a specific internal exception; it is not a general dry-run mode for arbitrary sequences.

Actions share the limits of their transaction. Several Queries, a Flow and Targets can collectively consume SOQL, CPU, heap and DML capacity. Keep query limits and collections proportionate to the work and test realistic input sizes.

A batch or chunk boundary can create a new transaction, but it does not guarantee that an individual scope is small enough. For CSV, reduce Rows per chunk when each source row triggers substantial automation.

Open the Job and inspect the earliest failed Action. Check its input, preceding outputs and any recorded metrics before changing downstream mappings.

If a configuration change is rejected, check required Action positions, missing references, unpublished outputs and forward references. A later output cannot be made available earlier by typing its path manually.

See Map data between Actions and Understand runtime behaviour and limits.