Use Data Queries when a Payload needs Salesforce data before it can build output or process input.

A Data Query runs as part of the Payload. The results can be used by Body Elements, Headers, Parameters, Modifiers, Data Targets, and troubleshooting views on the Job.

For the full runtime flow, see Understand Payload data flow.

Use a Data Query when the Payload needs values from Salesforce records, such as:

Do not use a Data Query for values already passed into the Payload as Dynamic Inputs. Query only when Salesforce is the source of truth for the value or when the Payload needs additional fields from a related record.

Open the Payload and go to the section that owns the output you are building.

For Full Callout, Outbound Webhook, Credential, and API Pull From Salesforce Payloads, Data Queries appear on the outbound side. The query runs before Payloads builds the outbound body, headers, parameters, and modifiers.

Give each query a clear name. That name becomes part of the mapping reference users see later, so use names such as Opportunity For Checkout or Account For Fulfilment instead of generic names such as Query 1.

A focused Data Query gives Elements a reliable Salesforce record to read from.

Open the query to review the full setup.

On the Object tab, set the Query Name, Object, Record Limit, Sort Field, Sort Direction, and any Child Relationships.

The Object tab controls which Salesforce records the Payload can read before mapping starts.

Payloads compiles the field list from the mappings that use the query. You do not need to maintain a separate list of selected fields. If an Element, header, parameter, or Target Field maps to Amount, Payloads includes Amount when it builds the SOQL.

A query should normally return the smallest useful result set.

For single-record mappings, set a record limit of 1 and use filters that identify the exact record. If the Payload receives a record Id as a Dynamic Input, use that input in the query filter. If the Payload is an inbound API, use a value from the inbound request only when it is stable and trusted enough for lookup.

Use filters to define which records are allowed into the result set. A filter criterion can compare a Salesforce field to a static value or to runtime data from the request, depending on the Payload type and section.

Filters decide which records are available to downstream mappings.

Use Record Limit to control how many records Payloads can return. Use Sort Field and Sort Direction when the first record matters. For example, if a query returns the latest matching Opportunity, sort by Close Date descending and keep the limit at 1.

API Pull From Salesforce Payloads can return data to another system, so their query can be the main output of the endpoint.

For API Pull From Salesforce Payloads, the Data Query often defines the data the caller receives.

Use Child Relationships when the Payload needs records under each parent record.

In the Stripe checkout example, the main query returns one Opportunity. The child relationship returns the OpportunityLineItems for that Opportunity. That child relationship is then used by the line_items Array Element, so each OpportunityLineItem becomes one Stripe line item.

Child relationship settings control the records available inside array mappings.

A child relationship has its own Record Limit, Sort Field, Sort Direction, and Filters. Keep these as specific as the parent query. If the child relationship feeds an outbound array or a multi-record target, the child result count controls how many array items or target records Payloads can produce.

After the query is configured, Body Elements and Data Target fields can use it as a source.

When mapping a field from a query, select the query name and the field name. If the query can return more than one record, make sure the mapping and target structure are designed for that. A single field mapping from a multi-record query can be ambiguous if the Payload is not built around that shape.

For request body mapping, see Map outbound request bodies.

Each run records the query output on the Job.

Use the Job when a mapped value is missing, stale, or different from what you expected. The Job shows which query ran, what SOQL was generated, how many records came back, and the field values Payloads used.

Job query output is the quickest way to confirm whether the mapping problem is the query or the Element using the query.

Before testing, check that:

After testing, compare the query output on the Job with the request body, response body, or target fields that used it.