Liquid Variables

Automations use Liquid variables to insert values from triggers and previous actions into text fields. You can use variables in places such as messages, private notes, Slack messages, HTTP URLs, HTTP headers, HTTP body templates, and Set variables values.

Basic syntax

Wrap a variable in double curly braces:

{{ trigger.ticketId }}

Variables are grouped by node name. If your trigger node is named trigger, ticket variables are available under trigger:

Ticket: {{ trigger.runningId }}
Customer: {{ trigger.customerId }}
Language: {{ trigger.language }}

If an HTTP request node is named lookupCustomer and creates an output named segment, later actions can use:

{{ lookupCustomer.segment }}

If a Set variables node is named setVariables and creates a variable named customerTier, later actions can use:

{{ setVariables.customerTier }}

Node names matter

Variable paths use the automation node name. If you rename a node, update any Liquid templates that reference that node. Use short, descriptive names such as trigger, lookupCustomer, setVariables, formatSummary, or routeByTier. The variable picker and AI automation tools use the app and customer names below. Existing templates using previous variable names continue to work.

Common ticket variables

Ticket triggers and manual workflows expose ticket-related variables such as:

Variable	Description
`ticketId`	The ticket ID.
`runningId`	The human-readable ticket number.
`url`	A link to the ticket in Theymes.
`app`	The app slug related to the ticket.
`language`	The ticket language.
`customerId`	The customer ID, when available.
`customerName`	The customer name, when available.
`email`	The customer email, when available.
`customerTier`	The customer tier, when available.
`channels`	The ticket channels.
`platform`	The customer platform, when available.
`supportSource`	The support source, when available.
`tags`	An array of ticket tag names.
`fields`	Custom field values, by field key.
`metadata`	Customer or device metadata.
`eventHistory`	Ticket event history.

Some trigger types expose extra variables. For example, Customer message exposes the latest message and message history, while Ticket events exposes the event that started the automation.

Common issue variables

Issue raised and Issue resolved triggers expose:

Variable	Description
`issueId`	The stable issue ID.
`alertId`	The ID of the specific raised or resolved alert occurrence.
`app`	The app slug related to the issue.
`title`	The issue title.
`issueType`	The issue type.
`status`	`NEW` or `RESOLVED`.

Some automation runs may not include alertId, as it is only being rolled out. Templates should handle cases where this variable is empty. Ticket created triggers expose the latest ticket state available when the automation runs. This can include updates made after ticket creation by Issue automations or other Ticket created automations. Ticket events and Customer message triggers also expose the current ticket details available when the automation runs, such as tags, fields, customer tier, and other ticket values. However, their message and event history variables are limited to the state at the time of the triggering message or event.

Custom fields

Ticket triggers and manual ticket workflows automatically expose custom field values under <trigger node name>.fields.<field key>. You do not need a Set variables action to access them. If your trigger node is named trigger and a custom field has the key accountType, use:

Account type: {{ trigger.fields.accountType }}

Use the exact Field key shown in the field editor, including capitalization. The key is separate from the field’s display name. Replace trigger with your trigger node’s name if you renamed it. Bracket notation also works and is useful for keys containing spaces or punctuation:

Account type: {{ trigger.fields["account-type"] }}

Missing values

A field that is not set on the ticket renders as empty. Use the default filter to provide fallback text:

Account type: {{ trigger.fields.accountType | default: "Not provided" }}

The default filter also replaces false. To keep a boolean field’s false value, use allow_false: true:

Consent: {{ trigger.fields.marketingConsent | default: "Not provided", allow_false: true }}

Field types

Field type	Value available in Liquid
Text	A string.
Number	A number you can compare or use in calculations.
Boolean	`true` or `false`. Compare explicitly with `== true` or `== false`.
Single-select dropdown	The selected option’s text, exactly as configured in the field editor.
Multi-select dropdown	An array of the selected options’ text.
Date	A date string you can format with the `date` filter.

For dropdown fields, use the exact option text, including capitalization. If the option is VIP account, check for "VIP account":

{% if trigger.fields.accountType == "VIP account" %}
This customer has a VIP account.
{% endif %}

Use numbers and booleans without quotes in conditions:

{% if trigger.fields.purchaseCount > 5 %}
This customer has made more than five purchases.
{% endif %}

{% if trigger.fields.marketingConsent == true %}
This customer has opted in to marketing.
{% endif %}

Format a multi-select field as a comma-separated list, or check whether it contains an option’s exact text:

Categories: {{ trigger.fields.categories | join: ", " }}

{% if trigger.fields.categories contains "Billing" %}
This ticket includes a billing question.
{% endif %}

Format a date field:

Purchase date: {{ trigger.fields.purchaseDate | date: "%Y-%m-%d" }}

These field keys and option values are examples. Replace them with the keys and values configured for your own fields.

Customer and device metadata

Built-in customer and device metadata is available under metadata, with values such as:

{{ trigger.metadata.sdkVersion }}
{{ trigger.metadata.osVersion }}

Use fields for custom fields and metadata for built-in metadata. Missing metadata values render as empty; you can use the same default filter shown above.

Workflow inputs

Manual workflows can ask the agent for inputs before running. Inputs are available under inputs on the workflow trigger node. For example, if the trigger is named trigger and an input key is escalationReason, use:

{{ trigger.inputs.escalationReason }}

Input keys must start with a letter and can contain only letters, numbers, and underscores.

Switch variables

Switch nodes expose information about the branch they selected:

Variable	Description
`selectedBranchId`	The selected branch ID.
`selectedBranchLabel`	The selected branch label.
`selectedBranchOrder`	The selected branch priority order.
`selectedIsFallback`	Whether the fallback branch was used.

For example:

Selected route: {{ routeByTier.selectedBranchLabel }}

AI Switch variables

AI Switch exposes the same selection variables as Switch, plus confidence (a number between 0 and 1). For AI Switch, selectedBranchOrder is the display position, not evaluation priority; it is null for fallback selections. selectedBranchId is fallback when Otherwise is selected. For example, if the node is named aiSwitch:

Selected route: {{ aiSwitch.selectedBranchLabel }}
Confidence: {{ aiSwitch.confidence }}

Per-choice probabilities are also retained in run results for inspection. Each entry contains value (the branch ID), label (the branch label, or the fallback label), and probability (a number between 0 and 1). Confidence does not affect routing.

Example Slack message

New ticket #{{ trigger.runningId }} from {{ trigger.customerName }}

Tier: {{ trigger.customerTier }}
Language: {{ trigger.language }}
URL: {{ trigger.url }}

Example HTTP JSON body

{
  "ticketId": "{{ trigger.ticketId }}",
  "ticketNumber": "{{ trigger.runningId }}",
  "app": "{{ trigger.app }}",
  "customerId": "{{ trigger.customerId }}",
  "language": "{{ trigger.language }}",
  "url": "{{ trigger.url }}"
}

Get started

Liquid Variables

Basic syntax

Node names matter

Common ticket variables

Common issue variables

Custom fields

Missing values

Field types

Tags

Customer and device metadata

Workflow inputs

Switch variables

AI Switch variables

Example Slack message

Example HTTP JSON body

​Basic syntax

​Node names matter

​Common ticket variables

​Common issue variables

​Custom fields

​Missing values

​Field types

​Tags

​Customer and device metadata

​Workflow inputs

​Switch variables

​AI Switch variables

​Example Slack message

​Example HTTP JSON body

Basic syntax

Node names matter

Common ticket variables

Common issue variables

Custom fields

Missing values

Field types

Tags

Customer and device metadata

Workflow inputs

Switch variables

AI Switch variables

Example Slack message

Example HTTP JSON body