Personalize case replies and notifications with template variables

Updated Wednesday, October 28, 2026 · Marc Staine

Template variables are placeholders that Supportbench replaces with information from the case, customer or notification being processed. Instead of typing the case number, customer name and portal link in every reply, your team can maintain a reusable message and let the supported workflow fill those values. This helps a B2B team communicate consistently across many contacts and accounts while keeping the message connected to the actual support record. The essential rule is to use variables supported by the place that sends the message: the same braces do not make a token universal.

At a glance

For: support agents, team leads and administrators maintaining reusable customer communications. Applies to: Supportbench Core.

Start here: Settings → Cases → Templates → open a template → Content

Understand the placeholder before using it · Choose the correct kind of template · Prepare a template that the right people can use · Insert variables in the Core template editor · Reference: case, customer and ownership values · Reference: links, knowledge, dates and custom fields · Use activity and suggestion content deliberately · Offer public source articles with an AI auto-response · Example: a clear equipment-investigation update · Test the message through the path that will send it · Troubleshoot missing or incorrect values

Understand the placeholder before using it

A token such as {{case_id}} is a piece of template text, not a command you run on your computer. The two opening braces, token name and two closing braces belong together. In a supported case message, Supportbench replaces it with that case’s identifier. Ordinary words around the token remain your message.

We have received your request {{case_id}} about {{case_subject}}.

The result might read “We have received your request c-12345 about Recurring pump alarm.” That case number and subject are illustrative. Your real output comes from the case being processed, not from the example in this article.

Variables save repeated data entry; they do not decide whether an answer is technically correct, whether a promise is authorized, or whether the recipient may see the information. An agent still needs to review the message and the customer context.

Choose the correct kind of template

Where you are writing	Use this rule
Case reply or case workflow notification	Use the case variables below and test the exact reply/workflow that will send the message.
Survey invitation	Case-triggered and scheduled campaign invitations have different data contexts. Follow the survey invitation guide; do not assume a campaign has a current case.
Custom chat transcript email	Follow the chat branding guide. The transcript body has its own required `{{chat_transcript}}` placeholder.
Customer-portal page	Use the supported Liquid objects, tags and filters. A portal Liquid expression is not automatically a case email token.
Signature or another system notification	Verify that surface’s supported variables and actual rendered output. The editor’s shared Variables menu is not proof that every listed item works there.

The shared menu can include {{activity_id}}
{{created_by}}
{{article_id}}
{{company_id}}
{{contact_id}}. These are context-dependent items, not a promise that every case-send path accepts them. Do not add a token just because its name looks plausible. Unsupported variables can cause a strict case translation to fail instead of producing a message.

Prepare a template that the right people can use

Confirm you can edit case templates. Administrators control template editing, and saving a Global template requires the additional global-template permission. If the editor is read-only, request the intended access rather than editing a different shared template.
Choose the intended audience and use: customer acknowledgement, agent-written progress update or internal handoff. Keep customer and internal wording distinct.
Select a representative test case with an approved test recipient, known Company/Contact, subject and ownership. Include a second case with optional values missing.
Check the template’s other settings, case options and attachments. Applying a template may do more than insert text; understand the existing configuration before reusing it.
Decide who owns future changes and how the team will recognize the template. A descriptive name such as “Customer progress update — equipment investigation” is easier to choose than “Template 2.”

Insert variables in the Core template editor

Open Settings → Cases → Templates. Open the intended template.
Select Content. Place the text cursor where the value should appear in the message.
Open the editor’s Variables dropdown and select the appropriate item. The editor inserts its literal placeholder at the cursor. You can also enter an exact supported token from this reference.
Write the complete sentence around the token. Leave normal spaces between words, but preserve the token’s spelling and braces. For ordinary case tokens use the exact lower-case form shown here.
Check the intended scope, other settings and attachments, then save the template using the editor’s save control. Reopen it to confirm the content was saved.
Apply the template to an approved test case using the normal case reply/template procedure. Review the inserted content and complete the controlled send test below before making it a team standard.

Applying a template and sending a message are different steps. The editor may still show literal variables after insertion; the relevant send path performs translation. A saved template or a successful Apply action alone does not prove that a customer will receive correctly rendered values. Applying a template to an existing case also requires permission to edit that case.

Reference: case, customer and ownership values

Variables	Meaning and operational guidance
`{{case_id}}` `{{case_subject}}` `{{case_summary}}`	Case identifier, subject and summary. The subject falls back to the summary if no subject is present. Review internal shorthand before putting a summary in customer correspondence.
`{{case_status}}` `{{case_priority}}` `{{priority}}`	Current case status and priority label; priority is an alternative priority token. A label does not independently explain the customer’s service commitment.
`{{case_issue}}` `{{case_outcome}}` `{{case_issue_breadcrumb}}` `{{case_outcome_breadcrumb}}`	Issue/outcome names, or their hierarchy joined with separators. An outcome value is not proof that the customer has accepted resolution.
`{{company_name}}` `{{contact_name}}` `{{contact_first_name}}` `{{contact_last_name}}`	Company and Contact in the notification context, normally the case’s relationship. Some notification paths supply a recipient-specific context. Missing company/name/first-name values can appear as “unknown”; do not assume automatic friendly fallback text.
`{{contact_email}}` `{{contact_phone}}` `{{contact_mobile}}`	Context Contact’s email, phone and mobile. contact_email is an email address, not the Contact’s full name. A saved phone extension is included with the phone value.
`{{case_contact_email}}` `{{case_contact_phone}}` `{{case_contact_mobile}}`	The primary Contact recorded on the case. Useful when recipient context differs, but do not expose another person’s details without a business reason.
`{{owner_name}}` `{{owner_first_name}}` `{{owner_last_name}}` `{{owner_initials}}` `{{owner_email}}` `{{queue_name}}`	Agent-owner and queue details. Owner full/first/last names are blank for a queue-owned case; initials and email have separate behavior and should not be treated as proof of agent ownership. Prefer a team sign-off when a case may remain in a queue.
`{{asset_name}}` `{{case_project}}` `{{case_project_version}}`	Associated asset, project and version names. Optional relationships may have no value; avoid sentences that become misleading when blank.
`{{activity_created_by}}` `{{case_created_by}}`	Recorded creators of the activity and case. These are different from the current owner and from the person expected to reply next.
`{{emailfrom_name}}` `{{emailfrom_email}}`	Name from the notification Contact context and sender address from the activity. Do not assume emailfrom_name independently parses a different sender’s display name.

Reference: links, knowledge, dates and custom fields

Variable or pattern	Use and limitations
`{{community_url_to_case}}`	Case link under the account’s default customer portal. It does not select a different portal for every company or grant access. Test with the intended customer identity.
`{{agent_url}}` `{{agent_url_to_case}}`	Agent workspace or agent case URL. Use for staff; customers normally need the customer-portal case link instead.
`{{community_url}}` `{{community_logo}}`	Default portal address and logo output. Numbered forms such as `{{community_url_123}}` and `{{community_logo_123}}` select the configured portal ID; 123 is an example, not a universal portal.
`{{linked_public_articles}}`	Generated links to eligible public articles associated with the case. Check the resulting links and the customer’s actual article audience; the token does not publish articles or remove access restrictions.
`{{activity_created_on}}` `{{case_created_on}}` `{{case_closed_on}}`	Recorded timestamps formatted in UTC unless a supported time-zone form is used. The case closure value may be a scheduled closure; inspect status before describing it as a completed closure. Missing dates become blank. In the case-list reply path, translation occurs before the new reply activity exists, so activity_created_on is blank; use that token only in a workflow with an actual Activity context.
`{{case_created_on \| 10}}`	Convert one of the three supported timestamps to a mapped zone. See the complete time-zone guide for IDs, format and daylight-saving behavior.
`{{date}}` `{{day}}` `{{month}}` `{{year}}`	Current UTC date/day/month/year at translation, not necessarily the case creation date or the recipient’s local date.
`{{f_5}}`	Custom field value identified by the actual field ID. The field’s configured location determines whether case, Company or Contact data is used. Verify the ID and representative value with the administrator; 5 is only an example.

A field can be empty because it is optional, applies to another record location or has not been populated. Fix the source data or write wording that does not require that field. Copying a field token from another Supportbench account does not guarantee the field ID has the same meaning.

Use activity and suggestion content deliberately

{{first_activity_content}}
{{last_activity_content}} insert selected activity content as HTML. The selected content can include internal activity text: these selectors do not enforce customer visibility. They are not a customer-safe redaction step. Do not put them into an unattended external message unless you have verified exactly which activity can be selected and that its content is appropriate for the recipient.

The shortened forms, such as {{first_activity_content_160}} and {{last_activity_content_160}}, convert selected content to plain text and limit its length. Use a numeric length of at least 2. Truncation can cut off a qualification or instruction; it is a preview, not a complete summary or privacy filter.

Knowledge and AI suggestion tokens such as {{article_suggestions}}, {{article_suggestions | 3}} and {{ai_suggestions}} depend on the applicable suggestion-processing path. They are not ordinary stored case fields. Confirm the feature and workflow support them, then review the suggested content and links. Never present an unreviewed AI suggestion as a confirmed diagnosis or service commitment.

Core’s case substitution is literal replacement. It does not provide a general HTML-escaping guarantee for every value you place in markup. Prefer normal text positions for customer-entered values, and have an administrator test any custom HTML. Do not construct scripts, styles or sensitive links from uncontrolled field text.

Offer public source articles with an AI auto-response

Use {{ai_suggestions | show_articles}} when recipients should be able to open the knowledge articles cited by an AI suggestion. The message contains the normal suggestion followed, when eligible sources exist, by Based on these articles and a list of linked article titles. Keep {{ai_suggestions}} for an answer without this extra list. The choice belongs to each template; existing templates do not acquire links automatically.

A citation identifies a source used in the generated answer. The list includes only cited articles that are currently available to an anonymous visitor in the account’s Default community. It does not list every search result. Private, unpublished, retired or restricted articles and articles outside that community’s topics or divisions are excluded. If source evidence changes during answer generation, the suggestion is invalidated and the existing no-suggestion fallback is used. If a cited source changes before the later link-generation check, its link may be omitted. An email recipient’s customer role is not used to unlock restricted sources. A portal that requires sign-in does not provide public citations for this option.

Confirm that the existing AI suggestion works through the intended Core case workflow or case-template processing path. This option adds source links; it does not enable AI or make an unsupported notification context support case suggestions. You need permission to edit the workflow or template.
Ask an administrator to review Settings → Account → Configuration / Style → URLs and Community. Select the intended Default community and check Community URL. A pattern such as https://help.example.com/article/{id} substitutes the cited article ID. A website root uses the native article route. If the field is blank, links use the default community’s custom domain, or its Supportbench alias when no custom domain is configured. See the account configuration guide before changing shared settings.
Open the intended notification or case template. Place the cursor where the answer should appear, open Variables, and choose AI suggestion with article links. You can also type the exact token. The existing AI suggestion choice inserts the answer-only form.
Write the greeting and service expectations around the token, then save and reopen the template. In Source mode, preserve the token as text inside appropriate email markup; the pipe is this token’s option, not a general Liquid filter.
Run an approved test through the actual workflow and inspect the delivered email. Check the answer, the linked titles and each destination in a signed-out browser. Test a second case without eligible public sources and confirm the message remains readable without a source heading.
Use the answer-only token wherever source links are unwanted. Removing the option changes that template; it does not change the account’s public article permissions.

Hello {{contact_first_name}},

These steps may help with your request {{case_id}}:

{{ai_suggestions | show_articles}}

If the issue continues, reply with what happened after trying the steps.

Cases created or updated through the Legacy API can use the same saved notification template and {{ai_suggestions | show_articles}} after the matching Legacy notification update is installed. Public-source, default-community and URL rules are the same. Test one API-created case through the intended workflow and inspect its delivered email; an API success response alone does not prove notification delivery. The Variables menu option described here is available in the matching Core editors; the exact token can also be entered in a template manually.

For example, if the answer cites “Check a recurring pump alarm” and that article is public in the default community, its title appears as a link below the answer. An unrelated article returned by search does not appear. For an account with separate customer and partner communities, the default community controls this list; the template does not choose another community based on the recipient.

Result	What to check
The answer appears without a source list	This is expected if no cited source passes public access, freshness and URL checks. Check the default community is active, has its knowledge base enabled, allows anonymous access and includes the article’s topic/division. Do not relax private article access merely to add a link.
The configured link is missing or incorrect	Reopen Community URL and verify the saved absolute HTTP(S) pattern and {id} placeholder. A fixed page path without {id}, malformed URL or missing portal address does not receive an alternative agent-workspace link. Test the real destination.
No supported answer is available	The existing AI fallback behavior still applies. Adding show_articles does not manufacture evidence or force a source heading.
The new choice is absent	Confirm the matching Core release is available and refresh the editor. Legacy editors do not expose this option. Do not assume every shared Variables menu or notification context supports AI generation.

For setup, see Configure the default community and article URL and Build and test workflows.

Example: a clear equipment-investigation update

Hello {{contact_first_name}},

We are continuing work on {{case_id}}: {{case_subject}}.

Current finding: [replace with the verified finding].
Next action: [state the action, responsible team and agreed update time].

You can review this request in your customer portal:
{{community_url_to_case}}

Thank you,
Customer Support

Before sending, replace both bracketed instructions, check the greeting, verify the recipient and read the link. The variables provide record context; the agent supplies the actual finding and next commitment. If your team cannot guarantee a first name, use “Hello,” rather than relying on an unsupported conditional expression.

Why this helps a B2B team

Several engineers at one customer may be working with different support agents. A consistent case reference and verified portal link help them recognize the same investigation. Keeping the next action and update time explicit prevents a polished template from becoming a vague “we are looking into it” response.

Test the message through the path that will send it

Save and reopen the template. Check for misspelled tokens, missing braces, unwanted attachments and any example instructions left in the text.
Use an approved test case and recipient. Apply the template through the same case reply or workflow route the team will use. Do not activate a broad automated rule merely to test formatting.
Review the actual resulting activity and delivered message where sending is involved. Confirm the case number, customer name, subject, links, selected content and dates. A queue/submit success is not proof of email delivery.
Open customer links with the intended customer test identity. An agent’s ability to open the destination is not a customer-access test.
Repeat with a queue-owned case, missing optional field and a different customer relationship where relevant. For time-zone output, include a known timestamp and the intended zone.
Only after the representative tests pass, make the template available to the intended team and record its owner and use. Retest when variables, workflow context, portal hostname or field definitions change.

Troubleshoot missing or incorrect values

Symptom	Likely cause and corrective step
A token remains visible	Confirm the message went through a translator that supports it, not just an editor preview. Check spelling, braces and the template context.
Sending fails after adding a variable	A strict case path may reject an unsupported token. Compare with the supported reference and test a corrected template through the same route.
The greeting says “unknown”	The notification Contact context has no usable name/first name. Verify the relationship and use neutral wording until the data is correct.
The owner name is blank	The case may be queue-owned. Use a team sign-off or confirm an actual agent owner; do not assign an agent solely to fill a greeting.
The wrong person’s details appear	Distinguish recipient-specific Contact context from the case’s primary Contact. Review the actual workflow recipients and use the appropriate token.
A customer link fails	Check the default portal URL, customer identity and access. Changing an agent link to a customer link does not grant authorization.
The time appears one hour different	Check the mapped zone, date and daylight-saving rules. Do not validate against a fixed-offset table.
A custom field is missing	Verify field ID, record location and stored data; do not guess the ID from its display name.
An internal note appears in a customer message	Stop using the activity-content shortcut in that external workflow and review selected activity content and recipient scope before resuming.

Was this article helpful?