Placeholders are references to ticket and user data that you include in the subject and body of email notifications. Without them it would be impossible to create automated messages. For the complete list of placeholders, and where they can be used, see Zendesk Support placeholders reference. When you specify placeholders, remember they are case sensitive.
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.
Related articles:
Using placeholders in business rules
The placeholders are contained within matched double curly brackets and are, in the following example, references to ticket properties. If a placeholder references a field that does not have a value, then the placeholder will be blank in the automation, trigger, or macro.
Here’s an example of how placeholders are used in an email notification:
When you’re composing email notifications, you can view the list of placeholders by clicking View Available Placeholders.
For the complete list of placeholders, and where they can be used, see Zendesk Support placeholders reference. If you want more control on how placeholder data is selected and displayed, see Understanding Liquid markup.
When you apply a macro containing a placeholder to a ticket, the placeholder is evaluated according to what is currently true about the ticket. If the output of the evaluation returns any information, it is added as a ticket comment. For example, if a macro that returns the ticket ID is run on a ticket that has not been saved (and therefore has no ticket number yet), the ticket comments will not be updated. The macro is not re-evaluated when the ticket is saved. You could manually add the placeholder to the ticket using the placeholder {{ticket.id}}. This would allow it to be evaluated when you submit the ticket, and the value returned by the placeholder would be added to the ticket comments.
Using placeholders for custom fields
Placeholders are generated automatically, based on the ticket and current user properties. These are referred to as system placeholders.
When you add custom fields for tickets, users, or organizations, they are also available as placeholders. You can use placeholders for your custom fields as you would any other system placeholder.
Every custom field has a unique ID or key. When you create a custom ticket field, the ID is automatically generated for you. When you create a custom user or custom org field, you enter a unique key that cannot be edited once it is set.
Custom fields are not included in the list of available placeholders, but they follow this simple naming pattern that references their unique ID or key.
Ticket custom fields | {{ticket.ticket_field_<field ID number>}} |
User custom fields | {{ticket.requester.custom_fields.<field_key>}} |
Organization custom fields | {{ticket.organization.custom_fields.<field_key>}} |
For example, a custom ticket field like this has the following placeholder:
{{ticket.ticket_field_505156}}
The placeholder name for the options in a custom drop-down list follows a different pattern. There's only one placeholder for all three drop-down list options because this is a reference to the option that was selected. The ID is for the custom drop-down list because options do not have IDs. Again, this is a reference to the single option that was selected.
Ticket custom drop-down fields
Ticket custom multi-select fields |
{{ticket.ticket_field_option_title_<field ID number>}}
{{ticket.ticket_field_<field ID number>}}
Note: The {{ticket.ticket_field_option_title_<field ID number>}} placeholder displays the title of the selected options while {{ticket.ticket_field_<field ID number>}} displays the tags associated with the selected options.
|
User custom drop-down fields | {{ticket.requester.custom_fields.<field_key>.title}} |
Organization custom drop-down fields | {{ticket.organization.custom_fields.<field_key>.title}} |
For example, the placeholder for a drop-down list for a custom ticket field would look like this:
{{ticket.ticket_field_option_title_515416}}
To find the ID for a custom ticket field
- In Admin Center, click
Objects and rules in the sidebar, then select Tickets > Fields.
- Locate your custom field in the list and then click Edit from the Options menu.
The ID is displayed in the right column:
To find the key for a custom user field or a custom organization field
- Open the configuration for User fields or Organization fields.
- In Admin Center, click
People in the sidebar, then select Configuration > User fields.
- In Admin Center, click
People in the sidebar, then select Configuration > Organization fields.
- In Admin Center, click
- Click the name of a custom field.
The field key appears in the properties panel on the right.
Using placeholders for a checkbox custom field
You can use placeholders in combination with Liquid markup to verify if a checkbox (custom field) has been selected on a ticket and provide customized output based on the checkbox status (checked, or not checked).
When you use Liquid markup if/else/case
statements for checkbox custom ticket fields, remember that the checkbox field has a value of 0 or 1, not false or true. For example:
{% if ticket.ticket_field_<insert field_id here> contains 1 %}
checkbox is checked
{% else %}
checkbox is unchecked (or null)
{% endif %}
43 Comments
Hi Chin Sin,
I've done a bit more testing on my end and you are correct, the placeholder does populate to the custom fields when using triggers + webhooks. As you noted, it does not populate as expected when testing using something like Postman. The reason for this is that when the webhook fires, it runs through a proxy which populates the placeholder field with the actual value before being sent to the specified endpoint. This does not occur when using Postman hence you see the placeholder sent as a string.
Sorry for any confusion but I hope this clears it up. Feel free to reach out with any questions!
Tipene
Hi Mike Konstantin,
Thank you for providing this solution! And thank you Rudolph Beaton for pointing it out. I've updated the article with this information.
Wooo, thanks for doing that, Colleen Hall!
the checkbox logic should actually be swapped.
should actually be
Screen Value: {{% if ticket.ticket_field_9508015623188 contains 1 %}}
Screen Value line, from above, does not work for getting if the checkbox was selected.
Hello, do placeholder work in the Email HTML template. For example, If I add an HTML signature and I use {{current_user.phone}} where the phone number would go, should it display the agent that responded to the ticket's phone number in the HTML signature? I have been unable to get any {{current_user.XXX}} placeholders to show anything in the HTML template.
I'm afraid the system placeholders like current_user.phone won't work when used within email templates. An alternate solution is to use the signature field in the user profiles; you can use these placeholders within that field. But, at this time, the signature field does not support HTML. You may only use Markdown formatting.
If you can, I suggest that you upvote or add a comment to this product feedback thread - Feature Request: HTML or Rich Text Editor for Signatures.
Thanks Albert!
Hi! Can this article please be edited to mention that placeholders are case-sensitive? I found this out today while working with a Zendesk agent to troubleshoot an issue I was encountering and I think it may be helpful to include it on this page.
I updated both these Placeholder articles to include the following sentence:
"When you specify placeholders, remember they are case-sensitive."
https://support.zendesk.com/hc/en-us/articles/4408886858138
https://support.zendesk.com/hc/en-us/articles/4408887218330
I'm marking this ticket as Solved. Let me know if you disagree.
Hi. I am trying to apply macro with placeholder {{ticket.requester.first_name}} when I create ticket via Zendesk API, but the placeholder won't be replaced in this situation. The placeholder only works when I update a ticket via API. Just wonder how to create a ticket with placeholder in comment via API? Thanks.
Ke Zhao,
Out of curiosity, are you running all of this in one command? If so, it won't work (from similar testing and work I've performed), as Zendesk doesn't understand who the Requester is until the ticket is actually saved with the Requester's details. It is best to perform this within two steps (first create the ticket, then have automation apply the Macro).
~Konstantin
Thank you for your quick reply, Mike Konstantin. I am running
GET /api/v2/macros/{macro_id}/apply
to get the comment from macro first, then call
POST /api/v2/tickets
Yes, I think you are right, Zendesk won't understand the requester. I had a workaround to create a ticket with a starting comment, then update the ticket with macro. Thank you!
I used a placeholder {{ticket.ticket_field_option_title_<field ID number>}} to show content from a Multi-Select Dropdown. The ticket itself looks fine, but when I search for it the results are showing the {{ticket.ticket_field_option_title_<field ID number>}} instead of the actual data. Is this a user error on my part or working as intended?
I have tried the placeholder below and it worked on my end. Make sure to use Cmd/Ctrl + Shift + V when pasting to avoid converting it to HTML.
Please sign in to leave a comment.