Troubleshoot Payload mappings with Job data
When a Payload does not behave as expected, start with the Job record.
The Payload record shows what should happen. The Job record shows what did happen: inputs, queries, outbound data, inbound data, target results, response status, errors, and runtime metrics.
For the configuration side of the same flow, see Understand Payload data flow.
Start with the Job header
Open the Job and check the header fields first.
Confirm the Payload, status, endpoint, response status code, response status, firing mode, created date, and any error message. This tells you whether you are looking at the right run and whether the problem is configuration, API response, target DML, or runtime behaviour.
If the Job failed, read the error before changing the Payload. A failed API response, missing query result, invalid Salesforce field value, and target DML error need different fixes.
The Job header is the fastest way to separate an API failure from a mapping or Salesforce write failure.
Check the runtime metrics
Open Metrics when you need to understand runtime cost.
Metrics show total runtime, CPU time, query count, DML rows, heap usage, callout duration, query duration, and DML duration. Use this when a Payload is slow, close to limits, or doing more work than expected.
Metrics help you decide whether the problem is an external callout, Salesforce queries, DML, or Apex limits.
Check Data Query output
If an outbound value is missing or wrong, check the Data Query output before changing the Element.
The Job shows the query name, generated SOQL, record count, object, and returned field values. If the expected field is not present, fix the query field list. If no record was returned, fix the query filters or the runtime input used by the filter.
Query output confirms whether Payloads had the Salesforce data needed for downstream mappings.
Check the outbound body
If the external API rejects a callout, inspect the outbound body, headers, parameters, and modifiers on the Job.
Compare the Job output with the external API documentation. This usually reveals missing required fields, an unexpected format, a value that was not transformed, or a query field that returned blank.
The outbound body on the Job is what Payloads sent, not just what the Payload was configured to send.
For request body setup, see Map outbound request bodies.
Check Data Target output
If Salesforce data was not created or updated correctly, check the target output on the Job.
The target output shows the object, operation, identifier, field values, record id, and success result. When a target fails, this is where you can see whether the wrong record was identified, a required field was missing, or Salesforce rejected a value.
Target output shows the exact values Payloads attempted to write into Salesforce.
For target setup, see Configure Data Targets.
A practical troubleshooting order
Work through the Job in this order:
Confirm the Job belongs to the Payload and run you are investigating.
Check status, response code, and error message.
Open Metrics if the run was slow or limit-heavy.
Check Dynamic Inputs if the Payload was started by Flow, Apex, a button, or another Payload.
Check Data Query output before editing field mappings.
Check outbound body, headers, parameters, and modifiers before blaming the external API.
Check inbound body, headers, and parameters before editing Data Targets.
Check Data Target output before changing Salesforce fields or transformations.
Change one thing at a time, run the Payload again, then compare the new Job with the previous one.