Mapping Data Between Steps with Templating

The run context is the shared data of a run

Every run carries a context — a growing bag of data that your steps read from and write to. It starts with the trigger payload and accumulates each step's output as the run proceeds. When a step needs a value — an email address, an order total, a customer name — it doesn't hard‑code it; it references it from the context using a template token. This is how information flows from the trigger through your steps.

The context has two top‑level areas you reference:

• trigger — the trigger payload that started the run. If a new lead arrived with { email, name }, then {{ trigger.email }} and {{ trigger.name }} are available.
• steps.<step_key> — the output of an earlier step, keyed by its step key. If a step named lookup_customer produced a customer record, later steps read {{ steps.lookup_customer.id }}.

Writing a mapping

Anywhere a step's configuration accepts a value, you can enter a template token that the engine resolves against the context at run time. The pattern is:

• {{ trigger.<field> }} — a field from the trigger payload.
• {{ steps.<step_key>.<field> }} — a field from a named earlier step's output.

When the run reaches the step, the engine resolves each token against the current context and records the fully resolved input in the Run ledger, so you can see exactly what each step received.

How resolution works during a run

For every action, transform, and delay step, the engine resolves the step's templated inputs against the context accumulated so far. Two outcomes are possible:

• All references resolve — the step's resolved input is captured (marked simulated in a simulate run, or queued in a live run) and the step's output is added to the context under its step key, ready for later steps.
• A reference cannot be resolved — the engine records the step as failed with the list of unresolved references, and the overall run finalizes as partial. Unresolved references are the single most common data‑mapping mistake, and the ledger names each one so you can fix it precisely.

Because a step's output only enters the context after it runs, you can only reference a step that runs before the one referencing it — which is exactly what the depends_on dependency graph guarantees. Reference an upstream step, never a downstream or sibling one.

Order matters: depend before you reference

If step B reads {{ steps.A.something }}, then B must depend on A (directly or transitively) so that A is guaranteed to run first and place its output in the context. If you reference a step you don't depend on, its data may not be present when B runs, producing an unresolved reference. Wire the dependency whenever you wire the data.

Realistic example

A workflow triggered by StretchForms form_submitted has two steps:

1. add_contact — StretchCRM create_contact, mapping email to {{ trigger.email }} and name to {{ trigger.full_name }}. Its output includes the new contact's id.
2. welcome — StretchMail send_email, depending on add_contact, with the recipient set to {{ trigger.email }} and a body that references {{ steps.add_contact.id }} for a personalized link.

When simulated with { email: "sam@example.com", full_name: "Sam Ito" }, the ledger shows add_contact resolved its inputs and produced an id, and welcome resolved its recipient to sam@example.com and its link to the new contact id. Had they referenced {{ trigger.email_address }} (a field that didn't exist), welcome would have failed with an unresolved reference to trigger.email_address.

Tips

• Simulate with realistic payloads. Most unresolved references surface immediately when the sample data matches production shape.
• Reference upstream only, and add the matching depends_on so the data is guaranteed present.
• Use a transform step to pre‑shape messy data once, then reference the clean output from several later steps.
• Read the resolved input in the Run ledger to confirm a token resolved to what you expected — not just that it resolved.

Troubleshooting

A step failed with "unresolved refs." The named token points at data not in the context. Either the trigger payload lacks that field, or you referenced a step that hadn't run. Fix the field name or add the dependency, then re‑simulate.

The step resolved to a blank or wrong value. The token resolved, but to unexpected data. Check the exact field path and inspect the upstream step's output in the ledger.

Data from a sibling step is missing. Sibling steps in the same stage don't see each other's output. Add a depends_on so the producer runs in an earlier stage than the consumer.