Understand Payload data flow
A Payload run is a controlled movement of data.
Depending on the Payload type, data can start in Salesforce, arrive from another system, be supplied when the Payload runs, or come back in an API response. The Payload configuration decides which values matter, where they should be used, and what should be written back into Salesforce.
If you are still choosing the right Payload type, start with Choose a Payload type.
The main building blocks
Most Payloads use the same building blocks, even when the direction changes.
Dynamic Inputs are values passed in at runtime, such as a record Id from Flow or a session Id returned by another Payload.
Data Queries read Salesforce data before the request or response is built.
Elements describe body, header, parameter, and modifier values.
Transformations adjust a value before Payloads sends it, stores it, or returns it.
Data Targets write parsed values into Salesforce records.
Jobs show the request, response, query output, target output, errors, and runtime metrics for a run.
The practical question is not "where does Payloads store data?" It is "which part of the run should own this value?"
Outbound flow
Outbound Payloads start with Salesforce-side data.
A Full Callout, Outbound Webhook, or Credential Payload can use Dynamic Inputs and Data Queries to collect values. Payloads then maps those values into outbound Body, Header, Parameter, or Modifier Elements.
An API Pull From Salesforce Payload also builds outbound data, but it does not accept Dynamic Inputs. It reads the inbound request body, headers, or parameters, then uses Data Queries and outbound Elements to return a response to the caller.
In the Stripe checkout demo, Payloads queries an Opportunity and its OpportunityLineItems. It maps the Opportunity Id into client_reference_id, uses the OpportunityLineItems child records to build Stripe line_items, adds request headers and parameters, and sends the callout.
The Callout side shows the values Payloads will use to build the outbound request.
Use Configure Data Queries when the Payload needs Salesforce data before it can build the request.
Use Map outbound request bodies when you need to map those values into a JSON, form URL encoded, XML, or text body.
Inbound flow
Inbound Payloads start with data received from another system.
An API Push Into Salesforce Payload receives an HTTP request. An Email Service Payload receives an email. A Full Callout or Credential Payload receives an API response. In each case, Payloads parses the inbound Body, Headers, and Parameters, then makes those values available to Data Targets and response mapping.
In the Stripe event demo, the request contains the Stripe event id, payment status, Salesforce Opportunity id, and a line_items array. Payloads maps the Opportunity id to the first target, then uses the line_items array to create one follow-up Task per line item.
The Request side owns the inbound data and the target that writes it into Salesforce.
Use Configure Data Targets when the Payload should create, update, or upsert Salesforce records.
Use Map Data Target fields when you need to decide which inbound, outbound, query, static, Credential, or global value should populate each Salesforce field.
Jobs show what actually happened
The Payload record shows intended behaviour. The Job record shows runtime behaviour.
After a run, open the Job to confirm:
which Payload ran
whether it completed or failed
what endpoint was called
which request body, headers, parameters, and modifiers were sent
which inbound body, headers, and parameters were received
which Data Queries ran and what they returned
which Data Targets ran and which field values they attempted to write
how long query, callout, DML, CPU, and total runtime took
The Job record is the place to check whether the configured mapping behaved correctly at runtime.
For a step-by-step troubleshooting workflow, see Troubleshoot Payload mappings with Job data.
What to decide before building
Before you add fields, Elements, or Targets, decide:
what starts the Payload
what values the Payload needs before it can run
whether those values come from Salesforce, the inbound request, a Credential, or runtime input
what the external system expects to receive
what Salesforce should store after the run
what a support user will need to see on the Job if something fails
Good Payloads are usually small and explicit. Each query, Element, transformation, and target should exist because the integration needs that value.