Variables

Variables let a workflow use real data — the customer's name, the order total, a product link — instead of fixed text. You write them as {{path}} anywhere a node accepts text.

Browse Variables

You rarely need to type a path from memory. Every text field in the builder has a Browse Variables picker that lists the paths actually available at that point in the flow, with a sample value for each.

Use it. It only offers paths that exist for your chosen trigger, which is the single most common cause of a variable rendering empty.

Variable sources

Trigger payloads are raw

{{trigger.*}} is the provider's webhook body, passed through untouched. For Shopify triggers that means the exact JSON Shopify sends: flat, snake_case, prices as strings, ids as integers.

{{trigger.name}}                        → #1001
{{trigger.total_price}}                 → 49.00
{{trigger.financial_status}}            → paid
{{trigger.customer.first_name}}         → Jane
{{trigger.line_items[0].product_id}}    → 7654321098765

This is a deliberate trade-off. You get everything the provider sends rather than a curated subset — but you also inherit the provider's quirks.

Shopify payload gotchas

These trip people up regularly, because the webhook body is narrower than the Admin API resource of the same name:

• Orders have no top-level gateway. Use {{trigger.payment_gateway_names}}, which is an array.
• Orders carry an embedded customer, but that customer has no tags.
• Customers webhooks have no tags, orders_count, total_spent, or marketing-consent fields. Those exist on the Admin API customer resource, not the webhook.
• Checkouts have no id. The checkout is keyed by token.
• Carts have no currency, and no email or phone at all.
• Order Edited sends an edit summary. Read {{trigger.order_edit.*}}.
• Marketing Consent Updated carries only the customer id, phone, and {{trigger.sms_marketing_consent.state}}.

When the payload doesn't have what you need, add a Fetch Order, Fetch Product, or Fetch Collection node and read from that instead — those query the Admin API and return the fuller resource.

Node output

A lookup node makes its result available to everything after it. Drop a Fetch Order node and the order's fields become referenceable downstream, including fields the trigger payload never carried.

The usual pattern for Order Edited:

Trigger: Order Edited
  → Fetch Order  (lookup by {{trigger.order_edit.order_id}})
  → Template Message using the fetched order's fields

Saved variables

Save Variable stores a value under a key you choose, so you can compute something once and reuse it. It's most useful for values you assemble from several sources, or for keeping a message template readable.

Save Data is different — it persists data beyond the run, including saving a product review.

Loop items

Inside a Loop node, each item binds to a name you set (item by default):

Loop over {{trigger.line_items}} as item
  → {{item.title}}, {{item.quantity}}, {{item.price}}

Loops cap at 50 iterations by default so a large order can't run away.

Links and UTM tags

Don't paste raw URLs into messages. Use the Format link node — it adds UTM parameters and optionally shortens the URL, then exposes the finished link as a variable.

Defaults are utm_source=whatsapp and utm_medium=automation, which is what makes workflow traffic attributable in Revenue attribution.

Testing variables

The builder gives you two ways to check a variable before publishing:

• JSON preview on a node config shows the resolved payload with sample data.
• Preview walks the whole flow, so you can see each message rendered.

Sample values are illustrative — only the shape is real. A path that resolves in preview will resolve at runtime; a path that shows empty in preview does not exist on that trigger.

Troubleshooting

Next steps

• Node reference — which nodes produce output.
• Trigger reference — what each trigger sends.