Zendesk Dynamic Content

Zendesk dynamic content is a snippet of text defined once, translated per language and referenced by placeholder wherever it's needed. Dull, and it saves entire weeks.

How Zendesk dynamic content works

You create a dynamic content item with a name, a default language and a body. Then you add variants: the same item in French, German, Brazilian Portuguese, each one active or inactive independently.

The item gets a placeholder, in the form {{dc.your_item_name}}, and you use that placeholder instead of the text itself. When Zendesk renders it, it looks at the language of the user in context and serves the matching variant. No variant for that language, or the variant is inactive? It falls back to the default language, so a customer always gets something readable rather than a blank.

You can use it in the places that matter: macro bodies, trigger and automation notifications, email templates, ticket field and form titles, and the values in a drop-down field. Placeholders nest, so a dynamic content item can itself contain {{ticket.requester.name}} and personalise per ticket as well as per language.

Availability sits at a plan level, and the number of items you can hold is not unlimited, so check your account rather than assuming. Variants also have a size ceiling, which nobody discovers until they paste in an entire policy document.

The reason to do it early

Here's the situation you're avoiding.

Eighteen months in, you have forty macros, thirty triggers, a dozen automations and four email templates. Every one of them contains hard-coded English text. Support opens in Spain. Now somebody has to open every single rule, work out which of them send customer-facing text, duplicate each one with a language condition, translate the text, and keep the two versions in step for ever.

That's a project. A genuine, several-week, error-prone project, and the errors are the kind customers see.

Set dynamic content up on day one and the same expansion is: add a Spanish variant to each item, done. The rules never change. There is one rule per job, not one rule per job per language, and the translation work is a spreadsheet handed to a translator rather than an archaeology exercise across your admin settings.

Even monolingual teams benefit. Your support email address appears in nineteen places. Your escalation policy wording appears in six macros. When one changes, one item changes, and you are not searching for the four you forgot.

What to put in it

Not everything. An item for every sentence is unmaintainable in a different way.

Greetings and sign-offs. Repeated in every macro, changed whenever your tone of voice does.
Legal and policy text. Refund windows, data-handling statements, terms references. These get reviewed and they must be identical everywhere, which is exactly what a single source gives you.
Contact details and hours. Phone numbers, addresses, opening hours. All of them change, all of them are in more places than you think.
Autoresponder and satisfaction survey wording. The highest-volume text you own, and the most embarrassing place for an untranslated sentence.
Field and form labels. So a customer selecting a reason on a form reads it in their own language, which matters more than it sounds because a misunderstood form value routes the ticket wrongly.

Leave the ticket-specific body of a macro alone. If a sentence only ever appears in one macro and nobody else needs it, an item just adds a layer of indirection for no benefit.

Naming and maintenance

Names are the whole maintenance story, because a year from now you'll be looking at {{dc.item_47}} in a trigger and have no idea what it says.

Use a prefix convention: macro_greeting_formal, legal_refund_window, contact_support_hours. Group by purpose, not by where you first used it, since the second use is always somewhere you did not expect.

There's a bulk import and export path for variants as a file, which is how you actually work with translators. Export, send, import back. Doing it by hand in the admin interface is fine for five items and unbearable for eighty.

Two habits worth adopting. Review inactive variants periodically, because an inactive variant silently falls back to the default language and a customer receiving English in a German flow is a bug that never raises an error. And when you change an item, search your macros and triggers for anything that also contains the old text hard-coded, because the first version of a rollout always leaves a couple behind.

How it fits with the rest of multilingual support

Dynamic content handles the text your business rules send. It is one of three pieces and it doesn't cover the other two.

Help centre articles are translated in Guide, separately, with their own language versions. Agent-typed replies are still typed by an agent, so multilingual coverage means either multilingual agents, routing by language skill, or machine translation with all the caveats that carries.

What ties them together is the user language setting, since that's what every fallback decision is based on. Get language detection and the user profile field right first. Otherwise you have beautifully translated content being served in the wrong language, which is worse than not translating it at all. The wider setup is covered in multilingual support in Zendesk.

FAQ

Frequently asked questions

How many dynamic content variants can one item have?

One per language you've enabled, plus the default. Zendesk dynamic content variants are edited independently, so a missing translation falls back to the default rather than breaking the macro.

How does a dynamic content placeholder work in a macro?

You reference the Zendesk dynamic content placeholder in the macro body and Zendesk substitutes the right language variant at send time. That's what makes Zendesk multilingual macros possible without maintaining one macro per language, and the dynamic content variants are edited in one place.

What is dynamic content in Zendesk?

A named text item with per-language variants, referenced by a {{dc.name}} placeholder. Zendesk serves the variant matching the user language and falls back to the default when there's none.

Where can I use dynamic content placeholders?

Macros, triggers, automations, email templates, ticket field and form titles, and drop-down field values. Placeholders nest, so an item can also contain ticket placeholders.

What happens if a language variant is missing?

Zendesk falls back to the default language variant. That is a safe failure, and also a silent one, so review inactive variants periodically.

Does dynamic content translate help centre articles?

No. Guide handles article translations separately. Dynamic content covers the text your business rules and macros send.

Is it worth using if we only support one language?

Yes, for anything repeated: support hours, legal wording, contact details. One edit instead of nineteen, and no forgotten copies.

Set the boring things up before you scale

Duplicate tickets are the other thing that gets exponentially harder to fix later. Ticket Merger handles them from the day you switch it on.

Start free trial

14-day free trial. No credit card required.