Settingsbeginner

Snippet variables reference

Every dynamic variable available inside a snippet, what each resolves to, and what happens when the source data is missing. Plus the patterns that prevent awkward empty values.

3 min read

Snippet variables reference

Variables are placeholders inside a snippet that get replaced with real data when the snippet expands into a reply. They’re what makes a snippet feel personal rather than robotic.

Inserting a variable

In the snippet editor toolbar, click the Variable button (the { } icon) to open the Insert Variable popover, pick from the list, and the placeholder is inserted at the cursor. Inserted variables display as a small labeled chip (e.g. “Agent: First Name”) rather than raw curly braces, so you can see at a glance which variables a snippet uses.

You can also type the placeholder directly if you remember its exact key, e.g. {{contact.firstName}} — it renders as the same chip once the snippet content reloads.

Common variables

The variable picker groups variables into two categories: Agent and Customer/Caller.

Agent

  • {{agent.displayName}} — The responding agent’s display name
  • {{agent.firstName}} — The agent’s first name
  • {{agent.lastName}} — The agent’s last name
  • {{agent.fullName}} — The agent’s full name
  • {{agent.email}} — The agent’s email address

Customer/Caller

  • {{contact.name}} — The contact’s full name
  • {{contact.firstName}} — The contact’s first name (derived from the full name)
  • {{contact.lastName}} — The contact’s last name (derived from the full name)
  • {{contact.email}} — The contact’s primary email address
  • {{contact.phone}} — The contact’s primary phone number

Custom field variables

Contact-level custom fields are addressable too:

  • {{contact.custom.<key>}} — A contact-level custom field

There is no conversation-level custom field variable — only fields stored on the contact record can be referenced this way.

The <key> is the machine identifier, not the display label. Look it up in Settings → Custom Fields — every field shows its key in the editor.

What happens when a variable can’t resolve

Two scenarios:

  • Empty source value. The variable renders as an empty string. Hi , (with no name) — looks unprofessional but doesn’t break the send.
  • Unknown variable name. The variable renders as the literal text {{unknown_variable}}. The customer would see the curly-brace template directly. This is louder than empty, which helps catch typos before send.

Avoiding empty-name awkwardness

If a contact only has an email (no parsed name), {{contact.firstName}} renders empty and your snippet starts Hi ,. Two patterns that handle this:

Pattern 1 — Conversational opener that doesn’t need a name:

Hi there,

Works for every recipient regardless of profile completeness. Slightly less personal but never broken.

Pattern 2 — Maintain contact records. Make sure every contact has a populated first name. Use Sidekick auto-population or an automation rule that pulls names from inbound messages.

Variables are evaluated at expansion time

When you type the shortcode and the snippet expands into the reply editor, the variables resolve immediately. You can edit the expanded text before sending — adjust phrasing, swap a word, add context. The variables are now plain text in your reply.

This means you can reach for a snippet before you know exactly what you’ll say, then refine after expansion. The variables save the typing of the predictable parts.

See also

Tags

Reference
Back to Settings