Payloads includes Flow actions for working with structured content.

Use them when Flow needs to convert a JSON, XML, or form URL encoded body into records, extract one value from a body, or read Data Target output from a Job.

These actions are useful when Flow needs a focused piece of structured-content handling but the whole process does not need to become a Payload. If the Flow is starting to model a complete API contract, it is usually better to move that structure into a Payload and let Flow orchestrate the process around it.

For running Payloads from Flow, see Use Payloads in Flow.

Use conversion actions when Flow has structured text and needs Salesforce records or record collections.

Payloads includes actions for:

Use object conversion when the source content represents one record. Use array conversion when the source content represents several records.

For example, use an object conversion when a JSON object should become one Account-like record variable. Use an array conversion when the source contains several line items, contacts, or other repeated records that Flow should handle as a collection.

Use extraction actions when Flow only needs one value from structured content.

Payloads includes extraction actions for JSON, XML, and form URL encoded content.

Provide the content and the Element key or path you want to read. The action returns the matching value so Flow can use it in decisions, assignments, or later actions.

This is useful when Flow does not need the full Payload model but still needs a specific value from a body. Keep the extraction focused; if the Flow needs many values from the same structure, a Payload model is usually easier to review and troubleshoot.

Use the Job Data Target action when Flow needs to read records produced by a Payload run.

For example, Flow might run a Payload, then fetch the Data Target output from the Job so it can continue with the Salesforce records Payloads created or updated.

This is usually cleaner than trying to duplicate the target mapping logic in Flow. Let Payloads handle the integration-specific write behaviour, then let Flow decide what the wider business process should do next.

Choose conversion when Flow needs a record-shaped output.

Choose extraction when Flow needs one value.

Choose Job Data Targets when Flow needs the result of Payload Data Targets after a Payload has run.

If Flow is becoming responsible for parsing a whole API contract, consider whether that structure belongs in a Payload instead. Payloads is usually easier to review and troubleshoot for integration-specific request and response modelling.

A useful boundary is this: Flow should own business process decisions, and Payloads should own integration shape, mappings, and runtime evidence.

Before activating the Flow, check that:

After testing, review the Flow debug output and the relevant Job record where a Job is involved. If the output is blank or malformed, check the source content and Element path before changing downstream Flow logic.