Use Payloads in Flow
Use Flow when a business process should decide when a Payload runs.
The Payloads Flow action lets a Flow choose a Payload, pass Dynamic Inputs, pick a firing mode, and receive the Job result. This is the normal pattern when a Salesforce process should call an external API after a user action, approval, record change, or screen flow step.
For one-off testing from the Payload record, see Run a Payload manually.
Before you add the action
Build and test the Payload first.
At minimum, confirm:
the Payload is the right type for Flow-driven execution
the Payload has a stable API Name
the Payload has the Credential, Endpoint, Method, content types, and Timeout it needs
any Dynamic Inputs have clear names
the Payload has been tested manually with realistic values
Flow is a good place to provide runtime values. It is not a good place to hide incomplete Payload configuration.
Add the Payloads action
In Flow Builder, add an Action and choose Payloads: Run Payload.
The custom configuration editor shows Payloads-specific fields:
Payload: the Payload the Flow should run.
Firing Mode: how Payloads should execute the run.
Batch Size: only used when Firing Mode is Batch Engine.
Dynamic Input fields: one field for each Dynamic Input used by the selected Payload.
The Flow action exposes the runtime inputs that the selected Payload expects.
Choose the firing mode
Firing mode controls how the Payload run fits into the Flow transaction.
Use Immediately when the Flow can make the callout in the current transaction and you want the returned Job result available straight away.
Do not use Immediately from the synchronous path of a record-triggered Flow. If a record-triggered Flow needs an immediate Payload run, put the action on an asynchronous path.
Use Immediate (No Commit) when you are chaining Payload steps and need callouts to run now while writes are staged until a later immediate step flushes them. Treat this like Immediately for Flow transaction planning: in a record-triggered Flow, use an asynchronous path.
Use Queueable Job when the Flow should hand off the work asynchronously.
Use Batch Engine when the work should be processed by Payloads' Batch Engine. Set Batch Size to control how many Jobs should be handled in each batch execution.
For more detail, see Configure the Batch Engine.
For simple screen flows, Immediately is usually the clearest starting point while testing. For record-triggered flows, start with an asynchronous path or an async firing mode unless you have a specific reason to keep the run synchronous.
Pass Dynamic Inputs
After you choose a Payload, the action shows fields for that Payload's Dynamic Inputs.
Map each Dynamic Input to a Flow value. Common examples are:
the current record Id
a field from a record lookup
a value entered on a screen
the Job result from an earlier Payload action
a value returned by another Flow action
Use the Dynamic Input names as a contract. If the Payload expects $OPPORTUNITY_ID, the Flow should pass the Opportunity Id that the Payload's queries and mappings are built around.
Use the Job result
The action returns a Job, a success value, and an error value.
Use the Job when the Flow needs to branch on the run result, show a confirmation, store a reference, or pass the Job into another step.
Check success before assuming the external work completed. For synchronous runs, success means the immediate run completed successfully. For async hand-offs, success means Payloads accepted the work for queueing or batch processing.
Common Flow patterns
A screen flow can let a user review values, select an option, then run a Payload with those selected values.
A record-triggered flow can run a Payload when a record reaches a specific state, such as an Opportunity moving to a payment-ready stage. Put immediate Payload actions on an asynchronous path, or use Queueable Job or Batch Engine when the Flow should hand off the work.
An autolaunched flow can chain several Payload actions together, using the Job from one step to decide what happens next.
Keep the Flow responsible for process timing and decisions. Keep request structure, credentials, mappings, transformations, and target writes in Payloads.
What to check
After testing the Flow, open the Job created by the action.
Confirm:
the correct Payload ran
the firing mode matches the Flow design
Dynamic Inputs contain the values you expected
Data Queries used those values correctly
the outbound request or inbound target output matches the business process
the Flow handles success and failure deliberately
For Job-level review, see Understand Job records.
If the action creates a failed Job, use Troubleshoot failed Jobs.