Skip to main content
Steps use {{}} syntax to reference dynamic data from the trigger and from previous step outputs. You can use these variables in any step’s parameters, prompts, or conditions. These variables appear inside a step. For the fields a whole definition takes, see the automation definition reference.

​
Available contexts

There is no {{payload.*}} namespace. The trigger’s fields are read by their bare names: {{order_uid}}, not {{payload.order_uid}}. That holds for every trigger type, including function, whose call arguments arrive as the trigger payload.

​
Reading the trigger

An ORDER_CONFIRMED automation reads the event’s fields directly:
A function automation reads its input_schema properties the same way, so an input named order_id is {{order_id}}. The engine owns seven roots: now, steps, platform, workspace, trigger_data, iteration and metadata. A trigger field sharing one of those names is shadowed, and the validator rejects the definition and tells you to read it through the envelope instead, as {{trigger_data.payload.metadata}}. Connection webhook triggers publish the provider’s raw body, so reach for the envelope there whenever the provider’s field names are not obvious.

​
Nested access

Variables support dot notation for nested fields:

​
Common patterns

​
Send notification on order

Event: ORDER_CONFIRMED
1

Send email

App action: send email to {{customer_email}}
2

Notify Slack

App action: post to Slack #orders channel

​
Abandoned cart follow-up

Event: CART_CREATED
1

Wait

Delay: 24 hours
2

Check conversion

Choice: check if {{cart_uid}} has been converted to an order
3

Send reminder

App action: if not converted, send a reminder email

​
VIP order routing

Event: ORDER_CREATED
1

Analyze customer

Custom agent: analyze customer order history and determine VIP status
2

Branch on VIP status

Choice: branch on {{steps.vip_check.is_vip}}
3

Route order

App action (VIP path): assign to priority fulfillment queue. App action (standard path): standard fulfillment.