Use Payload Data to pass a result from an earlier Action into a later one. A Query can provide a record field to an HTTP request; an HTTP response can provide values to a Target; a Flow can publish a calculated value for the response returned to an API caller.

The mapping belongs to the consuming Action. The producing Action must already exist earlier in the sequence.

For example, create an Opportunity Query before HTTP Request. In the request Body, map an amount Element from Payload Data, choose that Query Action and select Amount. For an API response value, define the response Element first, then choose HTTP Response as the source in the later Target Field.

An existing migrated mapping can still show a summary such as Data Query in the Body table. Open its editor to inspect the Payload Data source and Available Data selection.

Use the picker rather than typing an internal Action path. The choices reflect the current sequence and the shape of the selected output.

If a saved child Payload input shows No actions available when reopened in v1.53, cancel the edit and preserve the existing mapping. See the known issue in Call another Payload as an Action.

The mapping editor selects a producing Action and the field used by the consuming Element.

A single field is a scalar value, such as an email address or amount. A record collection contains several records. Match the selected source to what the destination expects.

For a multiple-record Target, Records From identifies the earlier collection to iterate. Its field mappings then read the appropriate values for each record. For an outbound Array, select the collection for the Array and map its children from the current item. Do not repeatedly select the first record when each item needs a different value.

For Query output, select a related parent field or child relationship where the picker supports it. A Query that returns no records cannot supply the expected field value; check the recorded query output when a mapping is blank.

Flow and Payload Actions expose only the outputs configured for later use.

In a Flow Action, select Publish for each supported output and give it an Output Name. In a Payload Action, add an output, select the child Action and Output & Field, and assign its Output Name. Save the producing Action before mapping that output downstream.

If an output is missing from a consumer's choices, check its publication, position and type. Do not replace the missing selection with a hand-written path to bypass those checks.

Static Value supplies a fixed value. Dynamic Input asks the caller or manual runner to supply a value at runtime, where that source is available. Global Variable supplies supported organisation, user, system or constant values. Credential sources appear in the editors where they are supported.

A Dynamic Input is not an Action output. Reuse the same input name only when the mappings are intended to receive the same runtime value. Follow the input naming guidance in the editor, such as $RECORD_ID.

Available value sources vary by editor and Payload type. Use the options shown for the mapping you are configuring.

A consumer can read only earlier Action outputs. An asynchronous inbound response cannot read results produced after the transaction boundary. A child Payload output must also have been explicitly published.

If a rename, deletion or output change is blocked, inspect the dependent mappings and update them first. After a test, compare the producing Action's recorded output with the consuming Action's recorded input or result.

Continue with Troubleshoot Payload mappings with Job data.