Skip to content

Email Template Variables — Operator Guide

Audience: Event Operators, Show Admins App: Show Admin (Marketing Settings + Email Templates) Related: [[email-template-variables-and-blast-snapshot|design SDS]] · [[reference/config-values|Marketing-API ConfigValue Catalog]] · [[tribal-knowledge/index|Tribal Knowledge]]


What this lets you do

Instead of cloning a whole email template every time a small piece of wording changes (a banner line, a venue note, a support address, a date), you can put that text in a marketing variable and reference it from the template. Change the variable once and every email that uses it picks up the new value — no template duplication.

This works today, with no engineering change.


How to add a marketing variable

  1. In Show Admin, select your show, then in the left sidebar go to Settings → Marketing. This opens the Marketing Settings page (the show's key/value list).
  2. Click Add setting and fill in:
  3. Key: must start with EMAIL_TEMPLATE_. Use uppercase, words separated by _. Example: EMAIL_TEMPLATE_VENUE_NOTE.
  4. Type: TEXT or TEXTAREA (use TEXTAREA for multi-line copy).
  5. Value: the text you want to appear.
  6. Save.
  7. In the email template, reference it with double braces: {{ EMAIL_TEMPLATE_VENUE_NOTE }}.

That's it. Any email for that show that includes {{ EMAIL_TEMPLATE_VENUE_NOTE }} will render your value.

Rules that matter

  • The EMAIL_TEMPLATE_ prefix is mandatory. A key without it will not appear in emails.
  • Scope is the whole show. The variable is available to every email for that show — that's what makes it good for shared snippets, but it also means it is not per-email.
  • The exact key is the exact variable name. {{ EMAIL_TEMPLATE_VENUE_NOTE }} in the template must match the key character-for-character.

⚠️ The biggest pitfall: do not edit during a send

The system does not freeze (“snapshot”) email content when a blast starts. Each recipient's email is built at the moment it is actually sent — which, for a large blast, is spread over many minutes.

That means: if you edit a template or a marketing variable while a blast is still going out, everyone who hasn't been sent yet gets the new version. The blast splits — some recipients get the old content, some get the new — with no record of who got which.

This has already caused a real incident. During a live event, a ticket email was edited mid-blast to add an urgent entry-procedure change. The first blast had not finished. Recipients ended up split across the old and new content, and a second full blast then went to everyone — confusing, and impossible to cleanly undo.

There is currently no “cancel blast” and no “snapshot” to protect you here. Until that is built (see the design SDS), the only safe rule is:

Finalize all content before you start a blast. Never edit a template or an EMAIL_TEMPLATE_ variable while a blast is in progress.

If an urgent change is genuinely unavoidable mid-blast: understand that the result will be inconsistent, there is no clean fix today, and you should coordinate with engineering before touching anything.


Other things to know

  • ~1 minute propagation delay. After you change a variable's value, it can take up to about a minute to take effect (values are briefly cached). If you change a value and immediately send a test, you may still see the old value — wait a minute and re-test.
  • Typos fail silently. If you reference {{ EMAIL_TEMPLATE_VENUE_NOT }} (typo) or a variable that isn't set, it renders as blank — no error. Always send a test to yourself and read the rendered email before blasting.
  • Test after every change. Because of the two points above, a test send is the only reliable way to confirm what recipients will actually see.
  • Large numbers of keys. Only the first 100 EMAIL_TEMPLATE_ keys for a show are loaded. This is a high ceiling for normal use, but don't rely on hundreds of these keys.
  • Empty/missing values. Some standard email variables have built-in defaults; brand-new custom keys simply show blank if unset.

Safe workflow checklist

Before a blast:

  • [ ] All EMAIL_TEMPLATE_ values for this show are set to their final text.
  • [ ] The template references the exact key names (no typos).
  • [ ] Sent a test email to yourself and read it rendered — no blanks, correct copy.
  • [ ] Waited ~1 minute after the last variable change, then re-tested.
  • [ ] Content is final and signed off — because once the blast starts, you cannot safely change it.

During a blast:

  • [ ] Do not edit the template.
  • [ ] Do not edit any EMAIL_TEMPLATE_ variable.
  • [ ] If something is wrong, stop and talk to engineering before changing anything — there is no clean self-serve fix today.

Coming later

A planned improvement will snapshot the template and its shared variables when a blast starts, so a blast always sends one consistent version, plus an explicit “cancel and re-send” control. Until then, the checklist above is the safeguard. See the [[email-template-variables-and-blast-snapshot|design SDS]] for the plan.


Last updated: May 18, 2026