Troubleshoot failed Jobs
A failed Job means Payloads tried to run the Payload and recorded a failure.
Do not start by changing the Payload. Start with the Job. It usually tells you whether the problem is the external API, Salesforce data, target mapping, credentials, limits, or the way the Payload was started.
For a field-by-field walkthrough of mapping output, see Troubleshoot Payload mappings with Job data.
Start with the failure summary
Open the failed Job and check the header.
Look at:
Payload
Status
Firing Mode
Endpoint
Response Status Code
Response Status
Error Message
Created Date
The response code and error message usually tell you which direction to investigate first.
The Job header separates API response failures from Payload configuration and Salesforce write failures.
If the external API rejected the request
An API failure usually has a response status code such as 400, 401, 403, 404, 409, or 500.
Check the response body first. External APIs often return the exact field, parameter, or authentication problem.
The response body is often more useful than the status code because it names the rejected value.
Then compare the outbound data with the API documentation:
Body
Headers
Parameters
Modifiers
Endpoint
Method
Credential placement
Compare the outbound body with the API documentation before changing mappings at random.
If authentication failed
Authentication failures usually show as 401, 403, or an API-specific error message.
Check:
the Credential selected on the Payload
whether authentication is being sent as a header, parameter, or body value as required by the API
whether the Credential value is present in the Job output where it should be
whether a Bearer Token Credential has a valid access token
whether the external API key or token is still valid
Credentials should normally own authentication values. Payload Headers should only hold request-specific values.
If a mapped value is missing or wrong
Check the data in the order Payloads used it.
First check Dynamic Inputs. If the caller passed the wrong value, the rest of the run may be correct but based on the wrong record.
Then check Data Query output. If the query did not return the expected record or field, fix the query before editing Elements.
Then check the Body, Header, Parameter, or Modifier that used the value.
Only change the Element once you know whether the source value was present.
If Salesforce did not create or update records
Open the inbound Data Targets section on the Job.
Check:
which Data Target ran
whether the target result completed or failed
which record id was used
which field values Payloads attempted to write
whether Salesforce returned a validation, required field, picklist, lookup, duplicate, or permission error
If multiple records should have been created, confirm the Data Target had a source array. Multi-record Data Targets need one source array entry per record.
If the Job is still New
New means the Job has been created but has not completed.
For Batch Engine work, check the Batch Engine queue and batch settings. For async work, check whether the queued Apex work has run. If the Job stays New longer than expected, an admin should check async Apex, scheduled jobs, and any Batch Engine configuration.
If the Job was slow or limit-heavy
Open Metrics.
Use the metrics to decide where the run spent time:
high callout duration points to the external API or network response time
high query duration or query rows points to Data Query design
high DML duration or DML rows points to Data Targets
high CPU or heap points to overall mapping complexity or large payload content
Metrics do not replace the error message. They help when the failure is related to limits, timeouts, or unexpectedly large work.
What to capture before escalating
Before escalating, collect:
the Job link
the Payload name
the Status, Response Status Code, Response Status, and Error Message
the outbound Body, Headers, Parameters, and Modifiers for API failures
the inbound Body and Data Target output for Salesforce write failures
the Metrics screenshot for performance or limit failures
the exact Flow, endpoint, email, or user action that started the Job
Change one thing, rerun the same scenario, then compare the new Job with the failed one.