Send Salesforce data to an external API from Flow
Use Flow to decide when a Salesforce record should be sent to an external API. Let an Outbound Payload own the API request, mappings and execution evidence.
Build the Action sequence
Create an Outbound Payload in the relevant Integration. Add a Query before HTTP Request to select the source Salesforce record. For example, query an Opportunity using a Dynamic Input such as $OPPORTUNITY_ID and limit the parent query to one record.
Select HTTP Request, edit Request Settings and configure Endpoint, Credential, Method, Content Type and Timeout. In its Body, Headers, Parameters and Modifiers, map the values required by the external API from the earlier Query output.
Select HTTP Response, choose the received content type and response policy, and model returned values needed later. Add a Target after HTTP Response if Salesforce should store a returned identifier or status.
Prove the Payload with one record
Use Run Payload with a test record Id. Review the new Job’s Start inputs, Query output, HTTP Request, HTTP Response and Target results. Confirm the record or external effect before adding Flow automation.
For repeating line items, use Build a parent and child request body.
Add Payloads: Run Payload in Flow
In Flow Builder, add Payloads: Run Payload. Choose the Payload and map its Dynamic Inputs to Flow variables. For $OPPORTUNITY_ID, supply the current Opportunity Id.
Choose a firing mode appropriate to the transaction:
Immediate is for a result needed in the current path, subject to callout and transaction constraints.
Queueable hands off the work; the Flow does not receive the finished business result immediately.
The general Batch Engine option rejects Actions Payloads containing Targets or Flows. Use a supported mode for those sequences.
For record-triggered processing, account for existing DML before an HTTP callout. Use an appropriate asynchronous path or Queueable execution. See Use Payloads in Flow.
Handle the result
For synchronous execution, inspect the returned Job and success/error values. For asynchronous execution, submission success means work was accepted; check the persisted Job after it runs.
Add a Flow fault path and make the operational owner clear. Avoid submitting another run automatically before checking whether the previous one made external changes.
Test the complete workflow
Run the Flow using a test record. Confirm the captured input Id, Query result, generated body, HTTP response policy and Salesforce write. Repeat with a controlled failure to verify the fault path and Job evidence.
For failures, start with Troubleshoot failed Jobs.