Zendesk Placeholders and Liquid

A Zendesk placeholder substitutes a value. Liquid adds logic on top. Together they're the difference between a notification that reads like a person wrote it and one that reads like a database.

Zendesk placeholder syntax, precisely

Two constructs, and mixing them up is the most common beginner error.

{{ }} outputs a value. {{ticket.id}} prints the ticket number.
{% %} runs logic and prints nothing. {% if %}, {% else %}, {% endif %}, {% for %}.

Write {{if ...}} and you get literal text in your customer email. Write {% ticket.id %} and you get nothing at all. Both mistakes ship regularly because neither throws an error, they just produce wrong output at send time.

Placeholders resolve when the message is generated, not when you save the macro, so the value is always the state of the ticket at that moment.

The objects worth knowing

Everything hangs off a handful of roots: ticket, current_user, and the user and organization objects reachable through the ticket.

{{ticket.requester.first_name}}, {{ticket.requester.name}}, {{ticket.requester.email}}
{{ticket.assignee.name}}, {{ticket.group.name}}, {{ticket.organization.name}}
{{ticket.id}}, {{ticket.title}}, {{ticket.status}}, {{ticket.priority}}, {{ticket.url}}
{{ticket.ticket_field_<id>}} for a custom field value, and there is a separate option variant for the drop-down label rather than the tag
{{current_user.name}} for whoever triggered the action, which is not always the assignee

Zendesk maintains a full placeholder reference and it changes, so treat any list you find elsewhere, including this one, as a starting point rather than gospel.

Comment placeholders, and the one that leaks

This section matters more than the rest of the article combined.

{{ticket.description}} is the first comment only, not the thread. {{ticket.latest_comment}} is the most recent comment. {{ticket.comments}} is the whole conversation. Each has an _html variant that preserves formatting rather than flattening to plain text.

Here is the trap. {{ticket.comments}} and {{ticket.latest_comment}} can include internal notes when the placeholder is rendered in a context that has access to them. If you put one of those in a notification that goes to the requester, you can send your customer the private note where a colleague described their request in less diplomatic terms.

Use the public variants, {{ticket.public_comments}} and {{ticket.latest_public_comment}}, in anything that reaches an end user. Then test it. Create a ticket, add an internal note that says something obviously identifiable, fire the notification at a test address and read what arrives.

Liquid in triggers and macros

The most valuable pattern is guarding against blanks. A requester with no first name gets "Hi ," at the top of your reply, which is a small thing that makes a company look careless.

{% if ticket.requester.first_name %}Hi {{ticket.requester.first_name}},{% else %}Hi there,{% endif %}

The same shape covers organization names, custom fields and anything optional. Branch on ticket properties too:

{% if ticket.priority == "urgent" %}We have escalated this and will respond within the hour.{% else %}We will respond within one business day.{% endif %}

Note the condition syntax. Inside a Liquid tag you reference the object without braces, ticket.priority, not {{ticket.priority}}. Nesting braces inside a tag is the single most common Liquid error in Zendesk.

Filters are available too. {{ticket.title | truncate: 40}} and {{ticket.requester.name | downcase}} both work, and they save a surprising amount of tidying.

Escaping and the gotchas

HTML in plain text. Using an _html placeholder in a plain-text email body sends the customer raw markup. Match the variant to the format.
Quotes inside conditions. Use straight double quotes. A smart quote pasted from a document breaks the comparison silently and the condition just evaluates false forever.
Whitespace. Liquid tags leave blank lines behind. If your emails have odd gaps, that is why. Keep tags on the same line as the text where you can.
Custom field IDs, not names. The field ID is stable, the name is not. Somebody renames a field and a name-based reference breaks.
Not every surface supports the same set. Coverage differs across triggers, automations, macros, email templates and dynamic content, and the API is different again. Test in the exact place you intend to use it.

And the one that costs the most: nobody tests the empty case. Make a ticket with no organization, no custom fields and a requester whose name is just an email address. That's the ticket that exposes every unguarded placeholder you wrote.

A workflow for changing them safely

Placeholders end up scattered across dozens of macros, triggers and templates, and there's no global find and replace. So treat them like code, lightly.

Keep a short document listing every custom field ID you reference and where. It takes ten minutes to write and saves an afternoon the first time somebody restructures your fields. When a field is deactivated, its placeholder doesn't throw an error, it just renders nothing, and a paragraph with a hole in it goes out to a customer.

Before editing a widely used macro, copy the current text somewhere. Zendesk does not give you a version history for macro bodies, and reconstructing a good reply template from memory is unpleasant work.

FAQ

Frequently asked questions

Where is the full list of placeholders?

In the Zendesk documentation, and it's long. The Zendesk placeholders list covers ticket, user and organization objects, and Zendesk Liquid markup is what adds conditionals on top. The Zendesk latest comment placeholder is the one to be careful with, because the public and private versions differ by one word.

What is the difference between double braces and percent tags in Zendesk?

Double braces output a value. Percent tags run logic and output nothing themselves. Using the wrong one produces literal text or silence rather than an error.

Which comment placeholder is safe for customer emails?

The public variants. {{ticket.public_comments}} and {{ticket.latest_public_comment}} exclude internal notes, while the general comment placeholders may include them.

Can I use if statements in Zendesk macros?

Yes. Liquid conditionals work in macros, triggers, automations and email templates. The most useful case is falling back to a generic greeting when a name is missing.

Why is my Liquid condition never true?

Usually curly braces inside the tag, or smart quotes instead of straight ones. Reference the object as ticket.priority inside a tag, with plain double quotes around the value.

How do I reference a custom field in a Zendesk placeholder?

By field ID rather than name, using the ticket field placeholder form. There is a separate variant that returns the drop-down label instead of the underlying tag value.

One personal reply beats two generic ones

Well-written placeholders make each message feel human. Merging duplicates makes sure the customer only receives it once.

Start free trial

14-day free trial. No credit card required.