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 the standard variables into two categories: Agent and Customer/Caller.

Agent

  • {{agent.displayName}} — The customer-facing agent name: the first word of the agent’s display name, unless the agent typed a custom 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

{{agent.displayName}} is meant for customer-facing replies. Use {{agent.fullName}} when you need the agent’s full name instead.

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

Conversation-level custom fields are addressable too, as {{conversation.custom.<key>}}.

The <key> is the machine identifier, not the display label. Look it up in the snippet editor’s Variable picker — every custom field is listed with its key under its label.

What happens when a variable can’t resolve

Two scenarios:

  • Empty source value. In a reply, the variable becomes a blank the agent must fill in before the reply can be sent. In a bulk reply, an empty customer or custom-field value renders as an empty string — Hi , (with no name). A signature leaves an empty variable out.
  • 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}} has no value: in a reply it becomes a blank you have to fill in, and in a bulk reply 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