> ## Documentation Index
> Fetch the complete documentation index at: https://docs.colossal.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Data access

> How to reference dynamic data in automation steps. Trigger payloads, step outputs, iteration items, and platform context.

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](/automations/definition) reference.

## Available contexts

| Context          | Syntax                           | Description                                                                                                   |
| ---------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Trigger payload  | `{{field}}`                      | A field of the payload the trigger published, read by its bare name                                           |
| Trigger envelope | `{{trigger_data.payload.field}}` | The same payload through its envelope                                                                         |
| Step output      | `{{steps.step_id.field}}`        | Output from a completed step                                                                                  |
| Iteration        | `{{iteration.item.field}}`       | Current item in a [map step](/automations/step-types#repeat-over-a-list), or in a `transform` with a `source` |
| Current time     | `{{now}}`                        | When the run started, ISO 8601                                                                                |
| Project          | `{{workspace.slug}}`             | Also `name`, `currency`, `storefront_url`. No other field resolves                                            |
| Platform         | `{{platform.field}}`             | Run identifiers: `trigger_entity_id`, `trigger_entity_type`, `org_id`, `workspace_id`                         |

<Warning>
  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.
</Warning>

## Reading the trigger

An `ORDER_CONFIRMED` automation reads the event's fields directly:

```handlebars theme={null}
{
  "to": "{{customer_email}}",
  "subject": "Order #{{order_uid}} confirmed",
  "body": "Thank you, {{customer_name}}. Your total is {{total_amount}}."
}
```

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:

```handlebars theme={null}
{{customer.email}}
{{steps.fetch_order.line_items}}
{{iteration.item.product.name}}
```

## Common patterns

### Send notification on order

Event: `ORDER_CONFIRMED`

<Steps>
  <Step title="Send email">
    App action: send email to `{{customer_email}}`
  </Step>

  <Step title="Notify Slack">
    App action: post to Slack `#orders` channel
  </Step>
</Steps>

### Abandoned cart follow-up

Event: `CART_CREATED`

<Steps>
  <Step title="Wait">
    Delay: 24 hours
  </Step>

  <Step title="Check conversion">
    Choice: check if `{{cart_uid}}` has been converted to an order
  </Step>

  <Step title="Send reminder">
    App action: if not converted, send a reminder email
  </Step>
</Steps>

### VIP order routing

Event: `ORDER_CREATED`

<Steps>
  <Step title="Analyze customer">
    Custom agent: analyze customer order history and determine VIP status
  </Step>

  <Step title="Branch on VIP status">
    Choice: branch on `{{steps.vip_check.is_vip}}`
  </Step>

  <Step title="Route order">
    App action (VIP path): assign to priority fulfillment queue. App action (standard path): standard fulfillment.
  </Step>
</Steps>