Skip to main content

Troubleshoot Payload mappings with Job data

Use Job records to inspect request data, response data, query output, target output, errors, and performance metrics for a Payload run.

Troubleshoot Payload mappings with Job data

Trace a wrong value through the Job's Action timeline from its producer to its consumer. The current Payload describes the configuration now; the Job provides evidence from the run you are diagnosing.

Find the earliest wrong value

Open the affected Job and confirm the Payload and run time. Check the first failed Action and the error before examining a later blank field.

Select Start to inspect captured inputs where available. Confirm that caller-supplied input names and values match the mappings.

Check the producing Action

For a Query, review the recorded query and returned records. Check filters, zero-result cases, sorting and collection size before changing a consumer.

For HTTP Request or HTTP Response, compare Raw and Tree views where available. Confirm that the expected property, header or parameter arrived, with the correct nesting and type.

For a Flow or child Payload, inspect its inputs and outputs and confirm that the required output was published. A result that exists inside the producer is not necessarily part of its public output mapping.

For a Target, inspect the records and outcomes. A later Action cannot use the ID of a record that failed to be created.

Check the consuming mapping

Return to the Payload and select the consumer. Review Value Source, producing Action and output or field. Check that the producer is earlier in the sequence.

For collections, verify Records From on the Target or the Array source in the Body. Map each item's values from the current collection context, and use outside scalar values only when repetition is intentional.

Check transformations, null behaviour, date or number conversions and the destination's expected type. For parent lookups, confirm whether Parent Field expects Id or an external key.

Recognise timing and historical limits

An early asynchronous Inbound response cannot include later Query, Target or Flow results. Move the requirement into an appropriate synchronous design rather than trying to enter a forward reference.

Historical Jobs labelled Recorded lack the full original Action snapshot. Use the saved values they expose without assuming they establish per-Action timing or original order.

For CSV, inspect source-row outcomes and chunk context. A failed row can still include successful records from another Target.

Verify the correction

Use controlled inputs to run the corrected configuration through its intended entry point. Inspect the new Job and compare the producer's output with the consumer's result. Confirm any actual Salesforce or external changes.

Did this answer your question?