How Do Zendesk Placeholders and Dynamic Content Work? (With Liquid Examples)

Zendesk placeholders are double-brace tokens such as {{ticket.requester.first_name}} that Zendesk replaces with live ticket, user or organization data when a macro, trigger or automation runs, and they use Liquid markup, so they can branch with if/else and fall back with filters. Dynamic content is the related feature for reusable wording: a centrally managed snippet with one variant per language, referenced in the same rules as {{dc.identifier}}. Dynamic content needs Suite Growth or above, or Support Professional or Enterprise. Every mechanic below was checked against Zendesk's placeholder documentation in September 2026.

What is a Zendesk placeholder?

A placeholder is a token that inserts dynamic data about the ticket, the user, or the organization into text at the moment that text is sent. Instead of typing a customer's name, you type a reference to where their name lives, and Zendesk fills it in when the macro is applied or the trigger fires.

Placeholders are written as output markup — a name wrapped in matched double braces:

{{ticket.title}}          → the ticket's subject line
{{ticket.id}}             → the ticket number, e.g. 41827
{{ticket.requester.name}} → the customer's full name
{{current_user.name}}     → whoever is updating the ticket right now

Under the hood there are two core data objects you're pulling from: the Ticket object and the User object. Almost every placeholder is a path into one of those — ticket.something for ticket data, and a user reference (ticket.requester, ticket.assignee, current_user) for people data. Once that pattern clicks, you can usually guess a placeholder before you look it up.

Which Zendesk placeholders are worth memorizing?

You don't need the full reference (it runs to hundreds of entries). These are the ones that cover the vast majority of real macros, triggers, and notifications.

Ticket data

{{ticket.id}}             {{ticket.title}}
{{ticket.status}}         {{ticket.priority}}
{{ticket.description}}    {{ticket.url}}
{{ticket.via}}            {{ticket.tags}}

The requester (the customer)

{{ticket.requester.name}}
{{ticket.requester.first_name}}
{{ticket.requester.last_name}}
{{ticket.requester.email}}

The assignee (the agent) and the current user

{{ticket.assignee.name}}        {{ticket.assignee.first_name}}
{{current_user.name}}           {{current_user.email}}
{{current_user.organization.name}}

current_user is subtle but important: it resolves to whoever is acting on the ticket at that moment, which is why it's the standard choice for agent signatures — the signature follows whichever agent replies.

Organization

{{ticket.organization.name}}
{{ticket.organization.id}}
{{ticket.requester.organization.name}}

Satisfaction (Legacy CSAT)

A quick caveat: the {{satisfaction.*}} placeholders belong to Zendesk's legacy CSAT feature. If you're on the newer customer-satisfaction experience, confirm these against your own account before relying on them.

{{satisfaction.rating_section}}   → the full, formatted "rate us" block
{{satisfaction.current_rating}}   → the rating's full text, e.g. "Good, I am satisfied"
{{satisfaction.positive_rating_url}}

Dropping {{satisfaction.rating_section}} into a solved-ticket notification is the normal way to attach a survey — Zendesk renders the whole prompt for you.

Does Zendesk use Liquid markup in placeholders?

Here's the part that elevates placeholders from "mail merge" to something genuinely programmable: Zendesk placeholders are powered by Liquid, the open-source templating language. That means alongside the {{ ... }} output tags you also get {% ... %} logic tags — conditionals, loops, and filters — so your templates can react to the data instead of just printing it.

A macro or trigger comment can branch on ticket fields:

Hi {{ticket.requester.first_name}},

Thanks for reaching out about "{{ticket.title}}" (ticket #{{ticket.id}}).

{% if ticket.priority == 'urgent' %}
We've flagged this as urgent and a senior agent is already on it.
{% else %}
We're on it and will get back to you shortly.
{% endif %}

Best,
{{current_user.name}}

You can also clean up missing data with filters. The default filter is the one to know — it stops a reply from awkwardly saying "Hi ," when a requester has no first name on file:

Hi {{ticket.requester.first_name | default: 'there'}},

And you can branch on more than one condition. A common pattern is checking a ticket field and falling through a chain of cases with elsif:

{% if ticket.status == 'solved' %}
Your ticket is resolved — reply here if anything's still off.
{% elsif ticket.priority == 'urgent' %}
This is flagged urgent and is at the top of our queue.
{% else %}
We've received your request and will follow up shortly.
{% endif %}

One Liquid gotcha catches almost everyone, and Zendesk documents it: checkbox fields evaluate to 1 (checked) or 0 (unchecked), not true/false. So test {% if ticket.ticket_field_360012345 == '1' %}, not == true. Zendesk's Liquid markup documentation lists the supported tags and filters in full.

Where can you use placeholders in Zendesk?

Placeholders work anywhere Zendesk lets you write text that's sent or applied as part of a business rule:

• Macros — the one-click canned responses agents apply manually. Placeholders are what make a single macro personalize to whichever ticket it's run on.
• Triggers — the event-based rules that fire on ticket create/update. The "Notify requester" and "Notify assignee" actions are placeholder-driven.
• Automations — the time-based cousins of triggers (e.g. a "still waiting?" reminder), which use the same notification actions.
• Email notifications generally, including system messages and agent signatures.

A practical note from inside the editor: placeholders are supported in some, but not all, business-rule actions. When an action supports them, Zendesk shows a View available placeholders button beside the field — if you don't see it, that field won't expand tokens. Lean on that button; it's the fastest way to find the exact placeholder name for a custom field.

Why does a Zendesk placeholder render blank?

Usually because of one of two documented rules. Both make placeholders look "broken" when they're working as designed.

1. Zendesk suppresses comment-body placeholders in creation triggers to stop spam. Zendesk suppresses the comment and description body placeholders ({{ticket.comments}}, {{ticket.description}}, {{ticket.latest_comment}}, {{ticket.public_comments}} and their formatted, HTML and rich variants) in trigger notifications only when five conditions all hold: "Anyone can submit tickets" is on, "Ask users to register" is off, the recipient is an end user, the message creator is an end user, and the trigger fires on ticket creation. The point is to keep spammer-supplied text out of notifications so nobody can use your account to relay spam. Notifications about later ticket updates aren't affected. If a comment body comes out blank in a creation trigger email, this safeguard, documented in Zendesk's placeholder suppression article, is the usual cause.

2. Problem tickets need an escaped placeholder to populate their incidents. When you comment on a Problem ticket, Zendesk can copy that comment to every linked Incident. To make a placeholder resolve against each incident (its own requester's name, say) rather than the problem ticket, escape it with a leading backslash:

Hello \{{ticket.requester.first_name}},

If a macro used on a Problem ticket greets every incident requester with the same wrong name, or leaves the token blank, reach for the backslash. The backslash itself is consumed, so each customer just sees their own name.

The broader principle: placeholder output is treated as untrusted text, so Zendesk escapes and limits it in places where unescaped substitution would be a security or formatting risk. Don't assume a token will render identically in every context.

What is dynamic content in Zendesk?

Placeholders pull live data. Dynamic content, available on Suite Growth and above and on Support Professional and Enterprise, is the complementary feature for reusable wording: centrally managed, localizable snippets of text that you write once and reference everywhere — and, crucially, that can carry language variants so the same reference renders in the customer's language.

Each dynamic content item gets its own auto-generated placeholder, shown right under its title in Admin Center. In business rules you reference it with the dc namespace:

{{dc.greeting}}

{{dc.refund_policy_v2}}

{{dc.support_signature}}

(In help center theme code the syntax differs slightly — {{ dc 'refund_policy_v2' }} — but in macros, triggers, and automations it's the {{dc.identifier}} form above.)

How an item is structured:

• It has one or more variants, each tied to a language (English, Spanish, German…).
• One variant is marked the default. This is the fallback: if the end user's language isn't one of your supported languages, or a particular variant is simply missing, Zendesk serves the default variant.
• The identifier is stable. Renaming the item's title later does not change its placeholder, so existing references keep working.

The admin screen for this lives under Admin Center > Workspaces > Agent tools > Dynamic content (it's behind your Zendesk login, so there's no public screenshot to show — but functionally it's a list of items, each opening to a table of language variants with one flagged as default, plus a References panel showing every macro, trigger, and automation using it).

How the two features work together

This is the combination that makes the feature genuinely powerful: you put placeholders inside dynamic content. A single greeting snippet can localize and personalize at the same time:

{{dc.greeting}}

…where the English default variant of dc.greeting is Hi {{ticket.requester.first_name | default: 'there'}}, and the Spanish variant is Hola {{ticket.requester.first_name | default: ''}},. Now one macro line greets every customer in their language, by name, with a graceful fallback — and you edit the wording in exactly one place. That central edit is the real payoff: change the snippet once and every macro, trigger, automation, and notification that references it updates instantly.

What mistakes break Zendesk placeholders?

What separates clean placeholder setups from fragile ones:

• Always add a default filter to name fields. {{ticket.requester.first_name | default: 'there'}} is the single highest-value habit. Customers without a stored first name are common, and "Hi ," looks careless.
• Test on every ticket type. A macro verified only on a Question ticket can misfire on a Problem ticket whose comments copy to incidents. Check both, and apply the backslash escape there.
• Use dynamic content for anything you'd repeat or translate — signatures, policy blurbs, greetings, closings. Hard-coding the same paragraph into twenty macros guarantees twenty edits later.
• Always set a default variant. A missing default is the most common reason a snippet renders blank for an unsupported locale. Every dynamic content item needs one.
• Reference, don't paste. Linking macros to a dynamic content item keeps wording consistent; copy-pasting the text defeats the entire point.

And the mistakes that generate support tickets about your support setup:

• Broken/typo'd placeholder names — {{ticket.requestor.name}} (misspelled) renders as literal text in the customer's email. There's no autocorrect; copy from the View available placeholders list.
• Assuming a value will always render — trigger suppression and ticket-type escaping both cause "empty" tokens. Empty usually means "working, but limited here," not "wrong syntax."
• true/false on checkboxes instead of '1'/'0'.
• Editing a snippet's title and expecting references to follow the new name — they follow the identifier, which never changes.

Where does AI fit alongside placeholders?

Placeholders and dynamic content are templating: they insert the right known value into pre-written wording. They're fast, predictable, and free — but they can't write the answer. A placeholder can greet a customer by name and stamp the ticket number; it can't read the question and explain why the refund hasn't landed.

That's the line where an AI agent layer like Macha comes in. Macha isn't a help desk and doesn't replace Zendesk. It runs on top of it, drafting context-aware replies from your knowledge base and ticket history instead of from a static template. In practice the two coexist: keep dynamic content for localized greetings, signatures and policy blocks, and let AI handle the variable middle, the part that has to be written fresh for each customer. Macha is one plan priced by ticket volume, from $299 a month for up to 750 tickets, and a ticket is charged once however many steps it takes to summarize, tag, route, draft and answer. Setup and monitoring by the Macha team are included. If your macros have grown into a sprawl of near-duplicate canned replies, that's the gap an AI layer fills; more in how to automate Zendesk with AI. The free trial gives you $50 of usage with no credit card required.

Frequently asked questions

What are placeholders in Zendesk? Placeholders are tokens — written in double braces like {{ticket.requester.first_name}} — that insert dynamic data about a ticket, user, or organization into macros, triggers, automations, and email notifications. When the rule runs, Zendesk replaces the token with the real value, so one template personalizes to every ticket.

Does Zendesk use Liquid? Yes. Zendesk placeholders are built on the Liquid templating language. Alongside the {{ }} output tags you can use {% %} logic tags for if/else conditionals and for loops, plus filters like default to control how data is selected and displayed.

What's the difference between placeholders and dynamic content? A placeholder inserts live data (a name, a ticket number, a status). Dynamic content is a reusable, localizable block of wording you manage centrally and reference with its own placeholder ({{dc.identifier}}). They combine: you can put data placeholders inside a dynamic content snippet so it both translates and personalizes.

How do I add dynamic content to a macro? Create the item in Admin Center > Workspaces > Agent tools > Dynamic content (give it variants per language and mark one as the default), then copy its auto-generated placeholder — e.g. {{dc.support_signature}} — and paste that into your macro, trigger, or automation text.

Why is my Zendesk placeholder showing up blank or as literal text? Three usual causes: a misspelled placeholder name (renders as literal text); Zendesk's anti-spam rules suppressing comment-body placeholders ({{ticket.comments}}, {{ticket.description}}, {{ticket.latest_comment}}) in a creation trigger when anyone can submit tickets without registering; or a Problem ticket comment copied to incidents, where the placeholder needs a leading backslash (\{{...}}) to resolve per incident. Confirm the exact name via the "View available placeholders" button.

What's the default variant in dynamic content? The fallback. If a customer's language isn't one you support, or a specific language variant is missing, Zendesk serves the variant you've marked as default. Every dynamic content item should have one, or it can render blank for unsupported locales.

Where do placeholders show up in day-to-day rules? Mostly in macros and triggers, and dynamic content also carries localized text through your help center, where theme code uses the {{ dc 'identifier' }} form.

Placeholder, Liquid and dynamic content mechanics checked against Zendesk's official documentation, September 2026. Zendesk updates its product periodically, so confirm specifics in your own account before relying on them.