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.
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 generate 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.<key_name>}} |
Organization custom fields | {{ticket.organization.custom_fields.<key_name>}} |
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.ticket_field_option_title_<field ID number>}} |
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
- Click the Admin icon (
) from the sidebar, then select Ticket Fields.
- Locate your custom field in the list and then click Edit.
The ID is displayed in the right column:
To find the key for a custom user field or a custom organization field
- Click the Admin icon (
) from the sidebar, then select User Fields or Organization Fields.
- 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 0 %}
checkbox is unchecked
{% else %}
checkbox is checked
{% endif %}
51 Comments
Hey Tech,
As far as I know the ticket.id placeholder should work in the ticket subject. What exactly are you seeing in the ticket subject when the email goes out to the agent or requester? Is it just showing the title?
Any chance you could provide a screenshot of the trigger as well as the test ticket you created?
Let me know!
Hi Brett,
That is correct. Only the title is being reflected on the auto-response subject line. Here is a screenshot of the trigger setup and the what the end user receives when they get the auto-response:
Trigger Setup:
Email Subject:
As you can see, only the {{ticket.title}} is showing but the [{{ticket.id}}] is missing.
Thank you!
Thanks for the update Tech!
I'm going to create a ticket on your behalf so our Customer Advocacy team can look into this for you.
We may need to do some testing with you to determine why this isn't showing up.
Cheers!
Can we add date custom fields too?
Hey Dominic Brasoveanu,
You can definitely use placeholders with ticket custom date fields. They follow the same syntax as any other field type. Just make sure you use the ID your custom date field.
Hi!
I just wanna know if there is a placeholder about the previous status before change is made, something like ticket.status.last_status
Thanks a lot!
Active Feature Request (please vote):
Feature Request: Add a placeholder about the previous status before the change is made
Alejandro González
I just posted a Feature Request for this at the link below. If you would like to see this feature please head over there and show your support. Please make sure to add an upvote and comment even if it is simply a "+1"
Also, you may consider adding it to your post to get the feature request more visible.
https://support.zendesk.com/hc/en-us/community/posts/360046934113-Feature-Request-Add-a-placeholder-about-the-previous-status-before-the-change-is-made
Adding a placeholder for a custom user field is not working for me.
The user field key is "llc_name":
I'm attempting to use {{ticket.requester.custom_fields.llc_name}} but nothing shows up. What am I doing wrong?
Hi Mark,
{{ticket.requester.custom_fields.llc_name}} looks valid to me, the only reason I can think of that you get no value returned is if the field is empty. If it's not, I'd suggest creating a ticket with Zendesk Advocacy, as it would look like unexpected behaviour.
Hi Dan,
I tried a few times yesterday and it wasn't working. Due to your confidence, I tried again and now it works. I must have been off on something. Thank you!
Glad to hear you got things sorted, Mark!
Is {{ticket.comments_formatted} still supported across all clients? I'm experimenting with the exact same example trigger/placeholders. The above placeholder renders in Gmail but it is not rendering in Outlook.
When I click "View Available Placeholders" it no longers appears which makes me think it's possibly not supported anymore...?
Hello John Bjorge
Firstly, the "View Available Placeholders" is actually a bit of a pain as it doesn't include a lot of the available placeholders in that list, often some of the most used ones! Sorry for any confusion caused by that! The place to go to get an exhaustive list of available placeholders is this article here: Zendesk Support placeholders reference.
The "{{ticket.comments_formatted}}" placeholder is definitely still supported. You can get an idea of how it works from this information (also in the above article):
It basically just includes the HTML of your comments rather than having an unformatted version go out. If the content isn't rendering correctly in certain platforms it is possible the platform itself is blocking some of the formatting.
I hope that helps!
Hi there!
Is there a placeholder that shows the number of Incidents assigned to a Problem ticket?
Hello Anderson Santos
I double checked in our Zendesk Support placeholders reference and the only placeholder I could find related to Problem tickets or Incidents is just the one that shows "ticket.ticket_type". So unfortunately I wasn't able to find any that shows number of incidents.
That being said incident count per problem ticket is definitely something you can report on, if you're interesting in seeing that data for your tickets in a report form. Explore recipe: Measuring the number of incidents by problem.
I hope that helps!
Hello team,
Is Liquid markup supported in Notify Target trigger? I am getting parse errors if I try to add markup to json response:
Thanks,
Hey Bojan,
Yes, Liquid works here, but the JSON validator in Zendesk fails when it sees the {{ }} placeholders. I'd fill it out using a fixed string for testing and then once the JSON is confirmed valid, replace it with the desired placeholder.
Hi Dan Ross,
I am not sure if I understand you. I created this response:
It is saved, but when I add this markup, trigger is not firing anymore. Is it badly formed?
I want to include all attachments name and url when new ticket is created and send it to webhook.
Thanks.
Bojan Nedeljkovic
I have had similar issues in the past.
My guess is the extra comma you have in the for-loop. I am guessing you put it there to separate multiple attachments but it will cause an error and not process the request if there is an extra comma.
I had to put in logic to omit the comma on the last iteration. I used the following code:
If that doesn't work then there are a couple of other things I would try.
First is as Dan mentioned, the "JSON validator in Zendesk fails when it sees the {% %} placeholders"
At this point, there is nothing you can do to fix the JSON validator that is on Zendesk. So, it is worthwhile to confirm that adding the attachments works without using Liquid code. If it works with a fixed string then you can change to a placeholder and it should still work, even with the JSON validator showing that error.
I would also check your Liquid code against something that will give you more information. Specifically, because of the lack of error information. What I do is create a temporary trigger and add the Liquid code to an email that will send even if the code is not working. That way I can troubleshoot the Liquid code itself. In this way, I can check to make sure the Liquid code added actually works separately from the request shown. The JSON validator is not going to be helpful in diagnosing an issue with the Liquid code.
Hi Alejandro Colon,
I did what you suggested, I have created a simple email trigger with following content:
{
"id":"{{ticket.id}}",
"attachments":[{% for attachment in ticket.latest_comment.attachments %}{"name":" {{attachment.filename}}","url": "{{attachment.url}}"}{% if forloop.last == false %},{% endif %}
{% endfor %}]
}
And I have received email with properly formed JSON this time (formatted in np++):
And now my trigger is finally firing as expected!
Thank a million to both of you guys, this is helping me a lot!
Bojan Nedeljkovic
At this point, I would take the fixed string (the output you received with the simple email trigger) and add it to the original request replacing the Liquid code for now. That will test the actual request.
If that does not work, then the issue lies with whatever is receiving the request. It might not be expecting it in that format or there is an issue with the space at the front of the name of the attachment. Something along those lines.
If it does work with the fixed string but does not work with the copied over Liquid code, then I would write it out instead of copying it and pasting it. That can sometimes cause issues.
If that does not work, I would reach out to Zendesk support. Liquid is supported. There might be some weird bug you are coming across. They should be able to replicate the issue and dig more into it at that point, as you have demonstrated the Liquid code does work outside of this specific request.
Please sign in to leave a comment.