Add a Query Action when later Actions need Salesforce records. Place it where the read should happen: before a request, after receiving external data, or after an earlier Target when you need a fresh read of updated records.

Use a name such as Opportunity For Checkout rather than Query 1. Later mappings identify this Action by its purpose.

For an existing Query, select its Action card and use Edit in the Query detail section. Follow Next through the editor as needed and save the completed configuration. New Query supports Save directly from its configuration tabs.

The Query editor controls the object, record limit, sorting and child relationships.

Return the smallest useful record set. For a single-record lookup, use a stable identifier and a limit of 1. Sort explicitly if the first matching record has a defined meaning.

A runtime filter can use Payload Data from an earlier Action, or another supported source offered by the filter editor. For example, an Inbound Query can compare a Salesforce external ID with a field from HTTP Request.

If using a Dynamic Input, supply its exact name through the runner or caller. A filter cannot read a later Action's result.

Payloads derives queried fields from the mappings that use the Query. Configure the consuming mappings rather than trying to maintain a separate field-selection list.

Use Child Objects in the editor to select child relationships when each parent record needs a collection of children. For example, query an Opportunity with OpportunityLineItems when the HTTP request needs one line-item object per child.

Configure the child relationship's filters, limit and sort order too. These control the collection available to Array Elements or multiple-record Targets.

Parent relationship fields can be selected in supported mapping pickers. Check that the relationship and field refer to the intended object.

In the consumer, set Value Source to Payload Data, select the Query Action and choose its field or collection.

Use a collection for a repeating Array or multiple-record Target. Use an appropriate single value for a scalar mapping. A multi-record Query does not make an arbitrary first record a reliable identifier.

A Query after a Target reads Salesforce at that point in the sequence. It can provide values changed by the earlier write or its automation, subject to the transaction's behaviour.

After testing, select the Query in the Job Action timeline. Review the recorded query, returned records and values, then compare them with the next consumer's output.

If no records were returned, check the actual filter value, user access and stored Salesforce data. A configured field name does not guarantee that a matching record existed during that run.

See Map data between Actions and Build a parent and child request body.