Mapping data between steps

Automations are useful because data flows through them. The trigger produces data, each action can produce more, and any later step can use any of it. Choosing which value goes into which field is called mapping.

Fixed values and variables

Every field in a step takes its value one of two ways, and you switch between them with the toggle on the field:

• Fixed — you type the value once and it's identical on every run. Use it for the list you always add to, the channel you always post in, a status you always set.
• Variable — you pick a value produced by an earlier step, and it changes with every run. Use it for anything that came from the event: the customer's email, the order total, the answer someone gave.

Most steps mix the two: a fixed destination, mapped content.

How do I pick a variable?

Switching a field to variable mode opens a picker listing everything available, grouped by the step it came from. Only steps that run before the one you're editing appear — you can't reference a value that doesn't exist yet.

Nested data is browsable: click into an object to see the fields inside it.

Why is a field missing from the picker?

Two common reasons, and both are worth knowing because they look like bugs:

The step has no sample data yet. The picker can only offer fields it has actually seen. Fetch sample data on your trigger before mapping anything — that's what populates the list.

The value was empty in the sample. Fields that were null or blank in the sample are left out. If a customer's phone number was empty in the record you fetched, "phone" won't be offered even though the field exists. Fetch a sample with the field filled in.

How do lists work?

Some data comes back as a list — the line items on an order, the answers to a repeating field.

• A list of simple values (tags, categories) is offered as one variable covering the whole list.
• A list of objects (line items, each with a name and price) lets you drill in and pick a field across every item — the name of every product, rather than one specific product.

For checking whether a list contains something, use the has item operator in a filter rather than trying to compare the list directly.

What about field types?

Fields are typed — text, number, date, checkbox, dropdown — and a mapped value is converted to the field's type when the step runs. A number field bound to a variable sends a real number, not text that looks like one. This matters because many APIs reject a string where they expect a number.

Dropdowns that load their options from the connected tool fetch the real list while you're configuring, so you choose an actual database, channel, or audience instead of pasting an identifier.

Can I use data from a sub-automation?

Yes, in both directions:

• A step after a sub-automation call can use values produced inside the automation that was called.
• A step inside a sub-automation can use values from the automation that called it, so a shared routine still has the caller's context.

What if a mapped value is missing at run time?

The field is sent empty. If the receiving tool requires it, that step fails and the run stops there. When a value is genuinely optional, put a filter ahead of the step so it only runs for records that have the data.