This recipe shows the most common outbound pattern: a Salesforce process decides that something should happen, then Flow asks Payloads to call an external API.

Use this pattern when the business trigger lives in Salesforce but the work happens somewhere else. Typical examples are creating a payment session, updating a fulfilment system, sending a customer record to a platform API, or notifying an internal service when a Salesforce record reaches a particular state.

For the full Flow article, see Use Payloads in Flow.

The finished setup has four moving parts.

The Payload stays responsible for API structure, credentials, mappings, transformations, and the Job trail. Flow stays responsible for timing and business decisions.

Create an Outbound Payload before opening Flow Builder.

At minimum, configure:

Use a manual run to prove the Payload works with realistic values. Flow should not be the first place you discover that the request body or Credential is incomplete.

Dynamic Inputs are the contract between Flow and Payloads.

If the Flow starts from an Opportunity, create a Dynamic Input such as $OPPORTUNITY_ID. The Payload's Data Queries can then filter from that input, and the request body can map fields from the queried Opportunity and its child records.

Do not pass every field as a Dynamic Input. Pass the stable identifier or small set of values the Payload needs to find the right data.

Create Data Queries on the Payload for the records the external API needs.

For a checkout-style request, the Payload might query the Opportunity and child OpportunityLineItem records. The Opportunity query gives the root transaction context. The line item query gives the array entries for products, quantities, and prices.

For query setup, see Configure Data Queries.

Build the outbound body so it matches the external API.

For simple fields, map body Elements to fields from a single-record Data Query. For repeated items, create an array Element and map that array to the child record query. Elements inside that array can then use fields from the current child record.

The request body should mirror the API shape, while the mappings decide where each runtime value comes from.

For more detail on array-backed mappings, see Build a parent and child request body and Map outbound request bodies.

In Flow Builder, add Payloads: Run Payload.

Choose the Payload, then map the Dynamic Input fields shown by the configuration editor. If the Payload expects $OPPORTUNITY_ID, pass the current Opportunity Id or another Flow variable containing that Id.

The selected Payload controls which Dynamic Inputs the Flow action asks for.

Use Immediately for screen flows when the user needs the result now. For record-triggered flows, put immediate runs on an asynchronous path. Use Queueable Job or Batch Engine when the Flow should hand off the work.

For runtime choices, see Understand runtime behaviour and limits.

The Flow action returns a Job, a success value, and an error value.

For synchronous runs, use the Job when the Flow needs to branch, show a confirmation, or pass the result into another step. For asynchronous runs, treat success as confirmation that Payloads accepted the work, then inspect the persisted Job after execution.

Run the Flow with a real test record.

Open the Job and check:

The Job proves what Flow passed to Payloads and what Payloads sent to the external API.

If the Job fails, use Troubleshoot failed Jobs.