A Job record is the audit trail for one Payload run.

The Payload record shows what should happen. The Job shows what actually happened: the runtime inputs, generated request, response, Salesforce writes, errors, and performance metrics for that run.

If you are testing a Payload from the UI, start with Run a Payload manually.

Open the Jobs tab when you need to find recent runs across the app.

You can filter by Integration, Payload, and Status. This is usually faster than opening an Integration or Payload first when you are responding to a support question.

The Jobs tab is the fastest way to find a run when you only know the Integration, Payload, or status.

The Job header gives you the run context.

Check these fields first:

Start with the header before checking lower-level request or response data.

New means the Job has been created but has not completed yet. This is common for Batch Engine work waiting to be processed.

Completed means Payloads finished the run and considered it successful.

Failed means Payloads recorded an error, a failed response policy result, or a Salesforce write failure.

Status tells you the broad outcome, but it does not explain the cause by itself. Use the request, response, target output, and error message to understand what changed.

Outbound data is what Payloads sent or prepared to send.

Depending on the Payload type, the outbound section can show:

Use this section when a value sent to an external API is missing, malformed, or different from the Payload configuration.

The outbound body on the Job is the request Payloads actually generated for that run.

For mapping-specific troubleshooting, see Troubleshoot Payload mappings with Job data.

Inbound data is what Payloads received or processed.

For an Outbound Payload, this is the external API response. For an Inbound Payload that writes Salesforce data, this is the inbound request. For an Email Handler Payload, this is the email content.

Depending on the Payload type, the inbound section can show:

Data Targets are especially useful because they show the records Payloads attempted to create, update, or upsert.

Target output shows the Salesforce write result for each configured Data Target.

Select Metrics when you need to understand runtime cost.

Metrics show total runtime, callout duration, query duration, DML duration, CPU time, query count, DML rows, and heap usage. Use them when a Payload is slow, close to limits, or doing more work than expected.

Metrics help separate API latency, Salesforce query cost, DML cost, and Apex limit pressure.

Use Replay Job when you want to repeat a run after changing configuration.

For most Payload types, Replay opens the runner modal with values from the Job already populated. For Email Handler Jobs, Replay reprocesses the captured email content.

Replay is useful for controlled testing, but treat it as a new run. Always review the new Job rather than assuming it matched the previous one.

Before asking a developer or admin to investigate, collect:

If the Job failed, use Troubleshoot failed Jobs.