Open the failed Job and identify the earliest failed Action before replaying anything. A failure can occur after an external request or some Salesforce work has already succeeded.

Confirm the Payload, time, firing mode, overall status and error. Expand the Action timeline and inspect the first failed step's data and measurements.

For queued work, inspect the associated asynchronous execution and the appropriate scheduler or Batch Engine. A queued Job is not necessarily failed just because it has not finished yet.

For HTTP Request, check the resolved endpoint, credentials, method, headers, parameters, body and timeout. Compare Dynamic Inputs and earlier Query output with the generated content.

For HTTP Response, check the actual status and body as well as the configured response Policy. A technically successful transport response can still fail the policy or omit data later mappings require.

For Query, check filters, record access and returned data. For Target, inspect individual record errors, identifiers, required fields, relationships, validation rules and type conversions.

For Flow, inspect mapped inputs, supported variables, the active Flow and its failure. Review DML before later callouts. For a child Payload, inspect its child execution and published outputs as well as the parent Action.

For email, check service matching, captured content and reply errors separately. A processing failure and a delivery failure are different problems.

If validation prevents execution, check required lifecycle positions and references. Consumers must use earlier outputs, and Flow or child outputs must be published. Child callouts must precede Targets.

If Salesforce reports uncommitted work before a callout, inspect Targets and DML performed inside Flows. A child Payload does not create an automatic transaction boundary.

Confirm what already changed before replaying. External side effects are not undone by Salesforce rollback, and partial success can leave valid records committed.

Replay uses current configuration and starts new work. Review prefilled inputs and choose identifiers or API idempotency mechanisms appropriate to the operation.

For CSV, use Troubleshoot and recover CSV imports. Earlier chunks can remain committed, Replay is disabled and a correction run must account for per-row mixed outcomes.

Provide the Job link, Payload, first failed Action, exact error and relevant input/output data. Include metrics for performance or limit issues and the native Apex execution details for scheduling failures.

Historical Recorded timelines expose saved data without inventing original per-Action timing or status. State that limitation when using an older Job as evidence.

See Troubleshoot Payload mappings with Job data.