Placeholders & Dynamic Content in Zendesk Explained

This guide covers two related features that beginners constantly conflate. First, placeholders: what they are, the common ones worth memorizing, the fact that they're powered by Liquid markup (so you get conditionals and loops, not just substitution), where they're allowed, and the security rules that quietly suppress or escape them. Then dynamic content: reusable, centrally managed, localizable snippets that you reference with a placeholder — the right tool for multilingual support and consistent wording. Every mechanic below is verified against Zendesk's own documentation.

What a placeholder actually is

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.

The placeholders 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.

Placeholders run on Liquid markup

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 that catches everyone: Zendesk 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 placeholders are used

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.

The security rules nobody warns you about

Two behaviors trip people up because they make placeholders look "broken" when they're actually working as designed.

1. Zendesk suppresses comment-body placeholders in creation triggers to stop spam. As an anti-spam measure, Zendesk automatically suppresses the comment and description body placeholders — {{ticket.comments}}, {{ticket.description}}, {{ticket.latest_comment}}, {{ticket.public_comments}}, and their formatted/HTML variants — in trigger notifications, but only when a specific set of conditions all hold: your account lets anyone submit tickets without registering (anonymous submission), the recipient and the message creator are both end users, and the trigger fires on ticket creation. The goal is to keep spammer-supplied content out of notifications so your account can't be used to relay spam. (It doesn't apply to update triggers, only creation.) If a comment body comes out blank in a creation trigger email, this safeguard — documented in Zendesk's placeholder suppression article — is the usual culprit. It's a feature, not a bug.

2. Problem and Incident tickets may need an escaped placeholder. On Problem-type (and Incident) tickets, a placeholder in a macro sometimes won't populate correctly unless you escape it with a leading backslash so Zendesk resolves it against the right object:

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

If a placeholder works fine on Question tickets but renders empty (or literally) on Problems/Incidents, reach for the backslash. The backslash itself is consumed — the customer just sees their 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.

Dynamic content: write it once, reuse it everywhere

Placeholders pull live data. Dynamic content 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 → 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.

Best practices and common mistakes

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 break on a Problem or Incident. Check both, and apply the backslash escape where needed.
• 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 AI fits

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 actual knowledge base and ticket history instead of from a static template. In practice the two coexist: keep dynamic content for your localized greetings, signatures, and policy blocks; let AI handle the variable middle — the part that has to be written fresh for each customer. Macha bills per AI action (any automated step — summarize, tag, route, draft, or resolve — costing 0.5–9 credits depending on the model you pick), not per closed ticket, because most of that work isn't a "resolution," it's drafting and triage along the way. 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. You can also try it free — 7-day free trial, 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 → 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 anonymous ticket submission is enabled; or a Problem/Incident ticket that needs the placeholder escaped with a leading backslash (\{{...}}) to resolve. 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.

The bottom line

Placeholders turn static Zendesk text into templates: {{ticket.requester.first_name}} and its siblings pull live ticket, user, and organization data into your macros, triggers, automations, and emails — and because they run on Liquid, you get conditionals, loops, and filters, not just substitution. Dynamic content layers reuse and localization on top: write a snippet once, give it language variants and a default fallback, and reference it everywhere with {{dc.identifier}}. Use the default filter religiously, always set a default variant, test across ticket types (mind the Problem/Incident backslash and the trigger-suppression rules), and reference snippets instead of pasting them. Do that and your support copy stays personal, consistent, and multilingual without the maintenance tax. From here, see how these tokens power your day-to-day rules in macros and triggers, and how localized content flows through your help center.

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