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 description (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 pre-formatted, 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. |
210 Comments
Hmm, actually, is there a way to find out the "via" of the latest update? I am trying to distinguish between updates from the API and all other updates.
Hello Charles, this should be visible in the ticket when you switch to the 'Events' view.
Let me know if that is not the case.
Thanks, Andrew, but I specifically meant with placeholders. There's a {{ticket.via}}, but there doesn't seem to be a {{latest_comment.via}}, which would be very handy.
I am trying to do something like this
{% if ticket.tags CONTAINS authorized_user %}
User is Authorized
{% else %}
ALERT: UN-AUTHORIZED USER
{% endif %}
What how do I write this?
Gaurav
Try this:
{% if {ticket.tags} contains 'authorized_user' %}
User is Authorized
{% else %}
ALERT: UN-AUTHORIZED USER
{% endif %}
Hi,
For real, I can't use ticket.organization.custom_fields.<key_name> with trigger emails?
Hi!

I'm trying to use satisfaction.rating_url, but it is not showing on the comment available placeholders... How do I use it on Macros?
Eduardo
I do not understand why some placeholders are missing from the predictive list. You can type or paste the placeholder and it should work fine.
{{satisfaction.rating_url}}
Hi,
How can I send the audit event logs of the ticket as a payload to the target (HTTP).
My aim is to process that event log to know the latest field changes, in particular a custom field.
Thanks.
Is there a way to see historical events in a PlaceHolder? For example, I send a mail when a certain type of ticket changes assignee.
I know that it changed, and I can identify the new (current) assignee. I'd like a way for the email I send to contain the previous ticket assignee.
Thanks!
Please tell me there is a way to get the "received_at" into a trigger's payload. I don't see a placeholder.
I agree with @Charles Wood. A "ticket.received_at" placeholder would be much appreciated. And a "comment.via" item in the "ticket.comments" objects that he mentioned previously would also be helpful.
Note that this is called "recipient" in the Ticket API: https://developer.zendesk.com/rest_api/docs/core/tickets#json-format
Also note that Comments do have a via property -- https://developer.zendesk.com/rest_api/docs/core/ticket_comments#json-format -- which implies it could be exposed as a placeholder.
Hi,
Is it possible to pull ticket.collaborators.} ?
Hello Mindaugas,
Yes, though to display this effectively you need a bit of code... try modifying the following to suit your application.
This is great, thank you,
Adding to Andrew's comment, the items in the "ticket.ccs" object are regular user objects, so each "cc" in the for loop has access to all the properties listed here: User data.
Earlier, {{target.cc}} was working even if CC was added during the current session of ticket editing. At present, it works only with CCs that have been added to the ticket before the current session. Which is not very convenient when using automation and adding CC during the same edit session.
Please advise.
Adding to Charles Wood, we also need the "via" placeholder for the latest update, to distinguish between API updates and other updates.
There's "Updated Via" in the triggers, and there's "via" in the comments object, so there's no reason this shouldn't be easily possible to implement.
It seems that ticket.comments_formatted doesn't take the 'Include attachments in emails' setting into account for previous comments, meaning that these are sent as links anyway. Not too handy when you want to send attachments, as actual attachments.
Is this a bug, or intended?
Hey Mike,
Thanks for submitting this question! The behavior you're seeing is expected at this time for threaded comments that come in after the initial attachment email. If we were to include the past attachments to each outgoing email it would require significantly more data to re-upload the each attachment to each individual message. Therefore to help cut down on that data processing we only add the attachments to the original email they were generated from, and provide the download link for any subsequent message replies that bring in the older comment with the comments placeholder.
I hope that helps clear things up!
Is there anyway to utilize liquid mark-up in macro titles? We support many countries and languages out of a central desk and utilize liquid mark-up for translation. The issue comes in with macros titles which we cannot get to work with liquid markup. Cloning macros per language is not an option either. Any solutions?
Hi Amber -
Unfortunately liquid mark-up and dynamic content do not work in macro titles. You'll have to just make all the separate macros for the different languages and sort them with the nesting functionality and a good naming convention.
Sorry I don't have better news for you on this one!
Can an automation be set up that would also send out an attachment that was attached to the ticket? Example: I have an automation for a ticket that is a billable feature request. I have a PDF of the work order attached to the ticket. When the ticket moves to solved I want the automation to grab that PDF and send it to my billing department saying this has been solved and here is the work order through an Email Target Notification. Can that be done?
It looks like it should be possible with the placeholders below, but when I put it in the automation or trigger ( {{ticket.commment.attachments}} or {{ticket.comment.attachment.workorder.pdf}} ) nothing happens. Any help would be appreciated.
comment.attachments
Hi Brian,
I think the issue with your example is that there is no "ticket.comment" field. You have to specify a particular comment (e.g., "ticket.latest_comment"), or get all comments ("ticket.comments").
See https://support.zendesk.com/hc/en-us/articles/203662156-Zendesk-Support-placeholders-reference#topic_jkz_opl_rc for specifics.
Charles,
Thanks for your comment but that hasn't solved the issue. I have tried a dozen different variants and I never get the attachments from a comment to email out on the trigger or automation.
Hi!
I want to generate json notification by trigger. But I have problem with array for attachments:
{
"attachments":[
{% for attachment in ticket.latest_public_comment.attachments %}
{
"fileName": "{{attachment.filename}}",
"url": "{{attachment.url}}"
}
{% endfor %}
]
}
It generates bad json in case of multiple attachments, comma is missed in json array. I tried this way {{ not loop.last ? ', ' }} but it doesn't work. How to do it?
There needs to be a place holder for "Next Business Day" so that if a out-of-office reply is sent via a trigger the response include the next day support will be available based on the set schedule or holiday.
Example:
Our support office is currently closed for {{ticket.current_holiday_name}}
Your request ({{ticket.id}}) has been received and will be reviewed by {{ticket.assignee.name}} on the ***{{next business day.}}***
Please allow additional time for us to reply when we return.
Hi
Is someone using ticket.latest_comment_rich?
Got rich text enabled on comments, yet the output of ticket.latest_comment_rich is always raw.
Any help is appreciated. Thanks.
Please sign in to leave a comment.