Zendesk Support placeholders are containers for dynamically generated ticket and user data. The format is a data reference contained within double curly brackets. Since you can also access ticket and user data when defining programming logic, it may be helpful to think beyond placeholders and think instead of data objects and their properties that can be used for either purpose.
There are two primary data objects in Zendesk Support: Ticket and User. Each has its own set of properties; the User object, for example, contains user properties such as name and email. In addition to these two data objects, there are associated data objects. For tickets, there are the Comment and Satisfaction Rating objects. For users, there are the Organization and Agent objects.
Although placeholders can be in HTML format, when a placeholder is sent to a HTTP or URL target, Markdown is used to render the placeholder, not HTML.
Support includes inborn system rules that suppress placeholders in triggers in certain situations. Inborn system rules are rules that you cannot change, modify, or override, which dictate the default behavior of Support. These rules may sometimes make it seem like placeholders in triggers failed to work, but this isn’t a mistake. These rules protect you because they prevent spammers from using your account to distribute spam messages. For more information, see Understanding placeholder suppression rules.
This article categorizes the placeholders by the data they display:
Related articles:
User data
- ticket.requester, who is the person who requested the ticket
- ticket.assignee, who is the agent assigned to the ticket
- ticket.submitter, who is either the user who submitted the request or the agent that opened the ticket on behalf of the requester
- current_user, who is the user currently updating the ticket (an end-user or agent)
This means that most of the user data listed in the following table can be returned for each type of user (for example, {{ticket.submitter.name}}, {{current_user.name}}, and so on).
Properties/placeholders | Description |
---|---|
user.name
Important: Remember to replace user with one of the user types shown above (for example, ticket.requester).
|
The user's full name. |
user.first_name | The user's first name. |
user.last_name | The user's last name. |
user.email | The user's email address. |
user.language | The user's language preference. |
user.phone | The user's telephone number. |
user.external_id | The user's external ID (if one exists). Optional for accounts that have enabled enterprise single sign-on using JWT or SAML. |
user.details | The user's details. |
user.notes | The user's notes. |
user.time_zone | The user's time zone. |
user.role | The user's role (Admin, Agent, or End-user). |
user.extended_role | When using Support Enterprise agent roles, this returns the name of the agent's Enterprise role. These are the predefined roles:
If you've created custom agent roles, those role names are returned. If you're not an Enterprise account, using this placeholder returns 'Agent' for all agent users. End-users are 'End-user'. For more information about custom agent roles, see Custom agent roles. |
user.id | The user's ID. |
user.locale | The user's locale (for example: en-US). |
user.signature | The agent's signature. Only agents have signatures. |
user.organization... | See Organization data below. |
user.tags | Tags. See Adding tags to users and organizations. |
Organization data
Each type of user can be added to an organization. An organization contains the following data properties.
Properties/placeholders | Description |
---|---|
user.organization.id
Important: Remember to replace user with one of the user types shown below.
|
The ID of the organization that the user is assigned to. |
user.organization.name | The name of the organization that the user is assigned to. |
user.organization.is_shared | True or False. Indicates if the organization is a shared organization. |
user.organization.is_shared_comments | True or False. Indicates if the organization allows users to add comments to other user's tickets. |
user.organization.details | Details about the organization. |
user.organization.notes | Notes about the organization. |
user.organization.tags | Tags. See Adding tags to users and organizations. |
- {{ticket.organization.name}}, which is the ticket requester's organization
- {{ticket.requester.organization.name}}, which the same as {{ticket.organization.name}} (the requester)
- {{current_user.organization.name}}, who is the user currently updating the ticket (an end-user or agent)
- {{ticket.assignee.organization.name}}, who is the agent assigned to the ticket
- {{ticket.submitter.organization.name}}, who is either the user who submitted the request or the agent that opened the ticket on behalf of the requester
Agent data
You can use the following placeholders in agent signatures only. For information on agent signatures, see Adding an agent signature to ticket email notifications.
Properties/placeholders | Description |
---|---|
agent.name | The agent's full name (or alias, if present). |
agent.first_name | The agent's first name. |
agent.last_name | The agent's last name. |
agent.role | The agent's role. |
agent.signature | The agent's signature. |
agent.email | The agent's email address. |
agent.phone | The agent's phone number. |
agent.organization | The agent's organization. |
agent.language | The agent's language. |
agent.time_zone | The agent's time zone. |
Ticket data
Zendesk Support tickets contain the following data properties.
Properties/placeholders | Description |
---|---|
ticket.account | The Zendesk account name. |
ticket.assignee.name | Ticket assignee full name (if any). See User data above. |
ticket.brand.name | The ticket's assigned brand name. |
ticket.cc_names | Returns the names CCs on the ticket.
Note: If you are using the new CCs and followers experience and you are adding or updating your placeholders, we recommend using
ticket.email_cc_names instead of tickets.cc_names . They do the same thing.If you want to return the email addresses of the people CC'd on the message, you can use this Liquid code:
|
ticket.email_cc_names |
With the new CCs and followers experience, returns the names of CCs on the ticket. With the old CCs experience, returns empty. Note: If you are using the new CCs and follower experience and you are adding or updating your placeholders, we recommend using
ticket.email_cc_names instead of tickets.cc_names . They do the same thing. |
ticket.follower_names | With the new CCs and followers experience, returns the names of followers. With the old CCs experience, returns empty. |
ticket.follower_reply_type_message | With the new CCs and followers experience, indicates what type of comment (public or private) triggered the notification. With the old CCs experience, returns empty. |
ticket.created_at | Date the ticket was created (for example, May 18, 2014).
Note: The year is not included if the ticket was created in the current year.
|
ticket.created_at_with_timestamp | Time the ticket was created expressed as an iso8601 format date/time. Example: 2013-12-12T05:35Z, which translates to December 12th, 2013 at 05:35am UTC. |
ticket.created_at_with_time | Date and time the ticket was created. For example, February 10, 14:29. |
ticket.current_holiday_name | If the placeholder is used outside of a holiday, it is null. If it is used within a holiday, the holiday's name is displayed. If you've set up multiple schedules, this placeholder respects the list of holidays set in the schedule applied to the ticket. |
ticket.description | The ticket description (the first comment), the agent's name, and the comment date.
Note: If the subject field is empty or not visible to the requester, then this first comment will be used and sent to the requester. This is true for private tickets as well.
|
ticket.due_date | The ticket due date (relevant for tickets of type Task). The format is: May-18. |
ticket.due_date_with_timestamp | The ticket due date (relevant for tickets of type Task) expressed as an iso8601 format date/time. Example: 2013-12-12T05:35+0100 which translates to December 12th, 2013 at 06:35am UTC+1. |
ticket.external_id | The external ticket ID (if one exists). |
ticket.encoded_id | The encoded ID is used for threading incoming email replies into existing tickets. |
ticket.group.name | The group assigned to the ticket. |
ticket.id | The ticket ID. #{{ticket.id}} creates a clickable link. {{ticket.id}} renders the ticket number in plain text. |
ticket.in_business_hours | True or False. True if the ticket update is during business hours. See Setting your business hours. |
ticket.link | Full URL path to ticket. |
ticket.organization.custom_fields.<key_name> | Property/placeholder format for custom organization fields. See Adding custom fields to organizations. |
ticket.organization.custom_fields.<field_key>.title | Property/placeholder format for the option title of a custom organization drop-down field. See Adding custom fields to organizations |
ticket.organization.external_id | External ID of the ticket requester's organization. |
ticket.organization.name | See Organization data above. |
ticket.priority | The ticket priority (Low, Normal, High, Urgent). |
ticket.requester.name | Ticket requester full name. |
ticket.requester.custom_fields.<key_name> | Property/placeholder format for custom user fields. For example, {{ticket.requester.custom_fields.my_custom_field}}. See Adding custom fields to users. |
ticket.requester.custom_fields.<field_key>.title | Property/placeholder format for the option title of a custom user drop-down field. For example, {{ticket.requester.custom_fields.manager_for_approval.title}}. See Adding custom fields to users. |
ticket.status | The ticket status (New, Open, Pending, Solved, Closed). |
ticket.tags | All of the tags attached to the ticket. |
ticket.ticket_field_<field ID number> | Property/placeholder format for custom fields. For example, {{ticket.ticket_field_123}}. See Placeholders for custom fields. |
ticket.ticket_field_option_title_<field ID number> | Property/placeholder format for the option titles of a drop-down custom field. For example, {{ticket.ticket_field_option_title_456}}. See Placeholders for custom fields. |
ticket.ticket_form | Form name for end-users. |
ticket.ticket_type | Ticket type (Question, Incident, Problem, Task). |
ticket.title | The ticket subject. |
ticket.updated_at | Date the ticket was last updated (for example, May18). |
ticket.updated_at_with_time | Time and date the ticket was last updated. For example, February 10, 14:29. |
ticket.updated_at_with_timestamp | Time the ticket was last updated expressed as an iso8601 format date/time. Example: 2013-12-12T05:35Z, which translates to December 12th, 2013 at 05:35am UTC. |
ticket.url | The full URL path to the ticket (excluding "http://"). |
ticket.verbatim_description | The plain text value of the ticket decription (the first comment). |
ticket.via | The source type of the ticket (Web form, Mail, Twitter, etc.). |
account.incoming_phone_number_ID | Zendesk Talk inbound phone number. For example,{{account.incoming_phone_number_123}}. |
Comment data
- Standard objects allow you to use liquid hashes to pick and choose what you want to display, and return a collection of comment and attachment data. For example, you can set up templates to iterate over comments using
{{ticket.comments}}
. - Formatted objects allow you to return preformatted, rendered HTML representations of the standard placeholders, but without a large degree of customization. They simply return comments in predefined formats. For example,
{{ticket.comments_formatted}}
returns a chunk of rendered HTML. The ticket comments will include dates, author, the author’s avatar, and the like. - Rich text objects allow you to use rich text in your customized template (as with the formatted object placeholders) without being restricted to the predefined formatting rules, so you can have more control over the look and feel of your notifications. However, rich text objects do not allow you to include attachments.
Properties/placeholders | Description |
---|---|
ticket.comments | Used as a placeholder, {{ticket.comments}} displays all the comments in a ticket in unformatted text.
Note: Agents will receive both public comments and internal notes; end-users will receive only public comments.
Ticket.comments also serves as a collection for comment and attachment details. You can access the following data using Liquid markup:
For an example of accessing this data in business rules, see Customizing the formatting and placement of text in comments and email notifications. Note: This same comment data collection is available when using the ticket.public_comments, ticket.latest_comment, and ticket.latest_public_comment placeholders.
|
ticket.public_comments | All public comments, most recent first. Unformatted text. |
ticket.latest_comment | The most recent comment. Unformatted text. Does not include attachments, unless Include attachments in email is enabled. To return attachments, use ticket.latest_comment_formatted.
Note: Agents will receive the most recent public comment or internal note; end-users will receive the most recent public comment.
|
ticket.latest_public_comment | The most recent public comment. Unformatted text. |
Properties/placeholders | Description |
---|---|
ticket.comments_formatted | All comments, most recent first.
Note: Agents will receive both public comments and internal notes; end-users will receive only public comments.
|
ticket.public_comments_formatted | All public comments, most recent first. |
ticket.latest_comment_formatted | The most recent comment including any attachments.
Note: Agents will receive the most recent public comment or internal note; end-users will receive the most recent public comment.
|
ticket.latest_public_comment_formatted | The most recent public comment. |
Properties/placeholders | Description |
---|---|
ticket.latest_comment_rich |
The most recent comment. Rich text formatting. Does not include attachments, unless Include attachments in email is enabled.To return attachments, use ticket.latest_comment_formatted. Note: Agents will receive the most recent public comment or internal note; end-users will receive the most recent public comment.
|
ticket.latest_public_comment_rich | The most recent public comment. Rich text formatting |
Satisfaction rating data
Properties | Description |
---|---|
satisfaction.rating_section | A formatted block of text prompting the user to rate satisfaction. |
satisfaction.rating_url | A URL to rate the support. |
satisfaction.current_rating | The text of the current satisfaction rating (e.g. "Good, I am satisfied"). |
satisfaction.positive_rating_url | A URL to rate the support positively. |
satisfaction.negative_rating_url | A URL to rate the support negatively. |
satisfaction.current_comment | The comment that the user added when rating the ticket. |
207 Comments
Thanks Jason Littrell ! That worked. I experimented and got it up to 2980 :-)
I see that in this reference the Answer Bot placeholders are missing. Why?
How can the whitelisting labels which are used for narrowing Answer Bot trigger searches be set using liquid?
The idea is that Answer Bot searches can be narrowed using the whitelist labels which are set in the trigger configuration.
If there are 10 products, say, and I want Answer Bot searches to be confined only to the product mentioned in the query body, then I would have to creat 10 Anser Bot triggers, 1 for each product.
Using liquid it would be possible to search for product names in the query body and then set the whitelist label. So, instead of having 10 Answer Bot triggers, only 1 Answer Bot trigger is necessary.
Hi, is there any placeholder showing only the first comment of the ticket weather it's a public or internal note?
Donald
Rather counter intuitive but you can get the first comment of a ticket with:
{{ticket.comments.last}}
Or you can use
{{ticket.description}}
Which will give some additional information on the assignee name, date and if the comment is private.
To assess if the fist comment is public, use:
{{ticket.comments.last.is_public}}
This returns true for a public comment and false if private.
@Graeme Carmichael
Thank you so much.
I have asked Zendesk to provide the available placeholders and modifiers that we can use. This is the first I have seen of the ".last" and ".is_public" those are very helpful.
Do you know of any others?
Alejandro
Most of the placeholders are detailed in this very article.
For help with the liquid language, I normally just google ' liquid markup' and some text about what I am trying to do and normally something pops up.
I need a little refresher from time to time as it is not something I need to do every day. But it is a great feature.
Hi, is there a way to get the email to which a support email was sent? We have multiple emails like help@companydomain, support@companydomain etc and I would like to use a placeholder with the specific email that received the ticket in a trigger.
What is your use case for this?
I'm creating a trigger that sends a bunch of ticket details to an external target which then inserts them into DataDog metrics. We would like to be able to filter our monitoring based on the support email that received the ticket.
Patrycja Mrowiec
I remembered in the API docs that you can query that info.
https://developer.zendesk.com/rest_api/docs/support/tickets
I don't have time to test but I would see if "ticket.recipient" would work. According to the API, it is listed as "recipient - The original recipient e-mail address of the ticket"
Hello,
I'm looking for a placeholder to get the first comment regardless if it's a public or private comment.
Hey Donald,
Unfortunately there's no first comment placeholder. You'd need to use either ticket.latest_comment_formatted to get the latest comment or ticket.comments_formatted which will give you a list of all comments. If you're an agent on the account you will see both public and private comments with those placeholders.
Let me know if you have any other questions!
Donald - I think you can access what you're looking for by using the 'last' method on the placeholder: `{{ticket.comments.last}}`
Hi Crawford Philleo,
I'm good with this. Thanks man for sharing this placeholder.
Though, my next dilemma is that if the first comment is private, only the agent can receive it. The one being sent to the customer is the first public comment.
Is there any way that the first private message can be sent to the customer?
Because for the cases that a light agent sent the first email on behalf of the customer, then a ticket will be created as an internal note. The agent will just change the requester to the customer's email. I would like to include it on the notification to the customer when the ticket has been solved.
Any workaround out there?
Thanks.
Donald,
> Is there any way that the first private message can be sent to the customer?
There is not. From my perspective as a longtime ZD user, this restriction is not only appropriate but essential. An important security feature of ZD is that we can be sure that internal comments will not accidentally be sent to the customer. Sometimes this causes some inconvenience, but the added security / privacy / confidence is well worth it.
If you want a fundamentally different workflow, you can code it using the API.
Or, more realistically for most support desks, write a macro to copy the oldest comment using {{ticket.comments.last}} as Crawford mentioned (though the fact that this is not formatted might sometimes be awkward), possibly with some additional boilerplate, and then send it manually as a public comment.
Is it possible to create a custom place holder somehow? We are a multibrand site and want to change the closing salutation in a macro based on the Brand assigned
Thank you for choosing {{ticket.brand.name}}, {{ticket.brand.slogan}} with the custom created markup slogan being different depending on the brand selected...
You could test ticket.brand.name value and then compute the slogan. This code isn't exact, but should get you started. Change the field to test and swap greeting for slogan and you are on your way...
{% if ticket.ticket_field_47199008 != blank %}
{% assign greeting = 'your order' %}
{% else %}
{% assign greeting = 'reaching out' %}
{% endif %}
Hi {{ticket.requester.first_name}},
Thanks so much for {{greeting}}! {% if ticket.ticket_field_47199008 != blank %}[[I'm so sorry...]]{% endif %}
[[Your message here]]
Please let me know if you have any other questions!
Thanks,
{{current_user.first_name}}
Thanks David - this is useful and gives me some ideas
Is there a placeholder for 'update_type' -> 'change' or 'create?
Hey Arne,
I did some digging on my end and it doesn't look like this placeholder is available at this time. I would recommend creating a feedback post in our Support Feedback topic and share your use-case for our product managers to review.
Thanks!
Thanks for looking, I found another solution so I wont need that after al.
I found serveral other problems with the placeholders unfortunatly.
- "comment.created_at_with_time" doesnt contain 'seconds' accuracy.
- There doenst seem to be way to get the 'via' or 'via_id' property from a comment.
Oddly enough when I print 'ticket.comments', I get a strangely formatted string of all the comments where via_id property is present & time_created DOES contain a timestamp with 'seconds' accuracy. But when I loop over the comments I'm unable to get those properties:
Looking like this: '[#<Comment id: 713910160240, account_id: 10577763, parent_id: 713910160000, ticket_id: 370169376299, author_id: 378252941419, created_at: "2021-01-29 16:03:06", via_id: 5, via_reference_id: nil, is_public: true, type: "Comment", value: "<p>test</p>#", value_previous: "rich", value_reference: nil, updated_at: "2021-01-29 16:03:06", notification_sent_at: nil>, [...omitted...] #<Comment id ...'
- ticket.status & ticket.priority return a translated and capitalized version, which is also not ideal
Hi Arne,
Similar to Brett's response above, your feedback on comment.create_at_with_time, via/via_id. ticket.status and ticket.priority will be best served by creating a post in our Support Feedback forum. We welcome your feedback, and we've provided a guide to creating an effective post here: Product feedback guidelines & how to write a good feedback post
As for the tickets.comments placeholder, that's functioning as designed - it allows you to use Liquid Markup to parse and format the comments in a customizable way: see Using Liquid markup to customize the formatting and placement of text in comments and email notifications. Hope that helps clarify things!
Hi Dave,
I've been struggling with the same problems as Arne: the `created_at_with_time` field's usefulness would be greatly improved if the field had at least second level precision, instead of minute. The `created_at_with_timestamp` placeholder exists for the ticket, so it's just a matter of porting it to the comment model as well. That would definitely solve my problem at least.
Another thing that would be immensely useful would be being able to list the ticket's custom fields without prior knowledge about what fields exist, similar to calling the `/api/v2/tickets` endpoint.
As for the weirdness in the `tickets.comments`: that looks like the standard output from printing a Ruby on Rails model (or using the inspect method). While I certainly can't argue about whether it is intentional or not, it is not usually a good practice, as it may lead to a couple of security problems down the road (without extra configuration, if you add extra fields to the Comment model they will show up in that representation whether you want it or not).
Hi !
I'm confused about which URL the placeholders {{ticket.link}} and #{{ticket.id}} point to. It looks like in some case, they render the URL in the help center (/hc/requests) and sometime the ticket's URL in the agent's space (/agent/tickets/) : is it agent's space in a notification to an agent and the help center's URL when sent to the requester and CCs ?
Which placeholder shall I use to get the link to the help center (/hc/requests) to communicate to an external user in a trigger/automation/macro/dynamic content ?
I would like to put the link to the request in the help center in a notification to the assignee (by automation), which can be transfered to end-users.
Hi Anaïs! Your understanding is accurate. {{ticket.link}} will show you a full URL:
-To agents, it will show yoursubdomain.zendesk.com/agent/tickets/123
-To end users, it will show yoursubdomain.zendesk.com/hc/requests/123
{{ticket.id}} only renders the ID itself and is only a clickable URL for agents. So it sounds like you'll want to use {{ticket.link}}!
Thanks for your confirmation, Madison.
I was imprecise in my message as to {{ticket.id}}, but I was refering to the formula #{{ticket.id}} which apparently behaves the same way as {{ticket.link}}, that is, according to the recipient/target, it renders a link to agent/tickets/ or hc/requests/.
So, using {{ticket.id}}, I could write the URL to the end user’s request page - hc/requests/{{ticket.id}}, but since I can’t put html code in the message area, there’s no way of sending the link to this page to an agent (I'm thinking of a message via automation) ?
Please sign in to leave a comment.