Passing data connects the steps in a mission. For example, a trigger supplies a bill ID, a lookup returns a supplier, and a message action uses both values.

​
Get a representative sample

Configure and test the trigger before mapping its output. Use a sample with the fields and value types you expect in production. If the app returns an empty array, there may be no matching event or record. Test each upstream action whose output you want to use. The builder uses those results to populate the data selector.

​
Insert a value

  1. Open the later step and select an input field.
  2. Open the data selector.
  3. Select an earlier step.
  4. Choose the output field you need.
  5. Test the receiving step and inspect its resolved input.
For a message, you can combine fixed text with dynamic values, such as Bill followed by the mapped bill ID. Keep structured inputs, lists and objects in the shape the action expects.

​
Inspect the shape

An app may return one object, a list of objects, a file reference or an empty result. A field named id in one gadget is not necessarily the same as id in another. Inspect the output instead of guessing paths. If you need one record from a list, choose it deliberately or use a loop. If a date or number arrives as text, transform it before comparison. See the function reference.

​
Branch and loop context

Inside a loop, use the current item. Outside the loop, do not assume a current-item value exists. In a branch, use outputs from steps that execute on that path.

​
Missing or changed fields

Refresh the upstream test sample when the source structure changes. Check the mapped path, null/empty values and the action’s required fields. Add a condition or default only when it reflects the business rule; a guessed default can hide an incomplete bill or missing account. After testing with one sample, test a second sample with a different ID so you can spot a hardcoded value.