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

# Liquid Variables

> Use Liquid variables to insert trigger data and outputs from previous actions into automation messages, requests, and other text fields.

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:

```liquid theme={null}
{{ trigger.ticketId }}
```

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

```liquid theme={null}
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:

```liquid theme={null}
{{ lookupCustomer.segment }}
```

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

```liquid theme={null}
{{ 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:

```liquid theme={null}
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:

```liquid theme={null}
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:

```liquid theme={null}
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`:

```liquid theme={null}
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"`:

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

Use numbers and booleans without quotes in conditions:

```liquid theme={null}
{% 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:

```liquid theme={null}
Categories: {{ trigger.fields.categories | join: ", " }}

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

Format a date field:

```liquid theme={null}
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.

## Tags

Ticket tags are available as an array of tag names under `<trigger node name>.tags`. Use the exact tag name, including capitalization, rather than a tag ID.

If your trigger node is named `trigger`, format the tags as a comma-separated list:

```liquid theme={null}
Tags: {{ trigger.tags | join: ", " }}
```

Check whether the ticket has a tag with `contains`:

```liquid theme={null}
{% if trigger.tags contains "VIP" %}
This ticket is tagged VIP.
{% endif %}
```

You can also list each tag separately:

```liquid theme={null}
{% for tag in trigger.tags %}
- {{ tag }}
{% else %}
No tags on this ticket.
{% endfor %}
```

An untagged ticket has an empty array. The `join` example renders an empty list, the `contains` condition does not match, and the loop above shows its fallback text.

## Customer and device metadata

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

```liquid theme={null}
{{ 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:

```liquid theme={null}
{{ 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:

```liquid theme={null}
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`:

```liquid theme={null}
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

```liquid theme={null}
New ticket #{{ trigger.runningId }} from {{ trigger.customerName }}

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

## Example HTTP JSON body

```json theme={null}
{
  "ticketId": "{{ trigger.ticketId }}",
  "ticketNumber": "{{ trigger.runningId }}",
  "app": "{{ trigger.app }}",
  "customerId": "{{ trigger.customerId }}",
  "language": "{{ trigger.language }}",
  "url": "{{ trigger.url }}"
}
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.