Recent searches


No recent searches

Zendesk Support placeholders reference



Edited Jan 06, 2025


35

169

169 comments

image avatar

Paolo

Zendesk Engineering

Hi Scott,
 
To return attachments, you can use the {{ticket.latest_comment_formatted}} placeholder. This will show the latest formatted comment with attachment. In addition, you may consider enabling the Include attachments in email as some placeholders will not render the attachment if this feature is disabled.
 
Best,
Paolo | Technical Support Engineer | Zendesk

0


Thanks Paolo, but that would then cause a duplicate of the most recent comment to show as we are using the other placeholder to get the entire comment thread visible.  
I ended up using {{ticket.latest_comment_attachments}} which is working for the most part.  I't would be better to have the option of {{ticket.attachments}} to be able to include all attachments. from the entire ticket history

0


I use this template and I'm able to get an array of attachments with filename and url properties.

{
   "ticketId": "{{ticket.id}}",
   "externalId": "{{ticket.external_id}}",
   "tags": "{{ticket.tags}}",
   "comment": "{{ticket.latest_public_comment_html}}",
   "attachments": [
    {% for comment in ticket.comments limit:1 offset:0 %}
      {% for attachment in comment.attachments %}
        {
          "filename":"{{attachment.filename}}",
          "url":"{{attachment.url}}"
        }{% if forloop.last %}{% else %},{% endif %}
      {% endfor %}
    {% endfor %}
   ],
   "authorId": "{{ticket.latest_comment.author.id}}",
   "status": "{{ticket.status}}"
 }

 

1


Is there a way of setting macros to have specific text depending on morning/afternoon/evening for the agent or requester's timezone? “Good Morning/Afternoon/Evening {{ticket.requester.first_name}},”

1


Hi Danny, 

ChatGPT says this, 

"Zendesk macros don’t natively support dynamic text based on the time of day. However, you can achieve this functionality using a combination of triggers and custom fields.

Here’s a potential approach:

  1. Create a Custom Field: Add a custom dropdown field to your tickets for time of day (e.g., Morning, Afternoon, Evening).
  2. Set Up Triggers: Create triggers to automatically set the custom field based on the time the ticket is created or updated. You can use conditions like “Ticket: Created” and “Time: Between” to set the appropriate time of day.
  3. Use Placeholders in Macros: In your macros, use placeholders to insert the custom field value into your greeting. For example:

    {{ticket.custom_fields.<custom_field_id>}} {{ticket.requester.first_name}},
    

This way, the greeting will dynamically change based on the time of day set by the triggers."

I think it could also be beneficial to have a couple of automations that change the custom field hourly. 

-1


Hi, 

i have add this test_tag user tag for some end user that open tickets.

I'm trying to build an if condition using liquid markup in a macro, but none of this work:

- {% if user.tags contains 'test_tag' %} → as in this documentation

- {% if requester.tags contains 'test_tag' %} → as in documentation that i have found in the help center..

It only work with this syntax:

{% if ticket.tags contains 'test_tag' %}

Someone can explain to me why?

It's because when i use the macro the user.tags don't pass the strings/arrays to the liquid markup condition of the macro?

0


Hi Riccardo, 

Why not make a trigger on ticket creation to copy the requester's tag to the ticket?

0


Is there a placeholder similar to {{ticket.comments_formatted}} for messages sent via chat? 

0


Good Day! 

 

Do you have placeholders for the “Customer Effort Score” survey? If there's none, how can I create an automation for CES surveys?

0


Am I missing something?  Are we able to edit the default placeholders or is this just explaining how these placeholders work?  If we CAN edit them - WHERE?  That isn't detailed anywhere in the KB.

0


struggling to see an answer here, but is there an placeholder for the ‘received at’ email address? 

0


D.Fitz I don't think so, we created a workaround for this. We created a custom drop-down field called “Email Received at” and then added all of our support emails as drop-down values. the we created a trigger to run when the channel is email and the ticket is created to set the custom field value to the same as the Ticket > Received at. Then you can use the custom field ID to reference it {{ticket.ticket_field_123}}. Example:

 

0


D.Fitz 

 

since it hasn't been a system field, or reportable in Explore for very long, one piece of workaround people have used for received-at is to create a custom field that's updated by a trigger to capture the received-at email in a drop down of their email channels. 

 

 ie if received at is xyz@abc.com update field-01234567 to xyz@abc.com. you can then use that custom field for a placeholder.  

0


Hi, Has anyone tried this placehodler? I could not make it work.

0


Hello, how do I get the update id in json? This ID must be unique for each update. I need to pass this id in the trigger via json. Thank you.

0


Бойко Андрій Ігорович 

 

I don't think that's available for placeholders, you would need to query the audit endpoint with the ticket ID to get the unique for the update. Here's a link to the documentation - https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/#list-all-ticket-audits

0


Is it possible to add the new CSAT placeholders? Thx

0


As other users have pointed out, it is wild that placeholders like “status” and “via” are in the user's language. In the case of webhooks at least, the main use case for placeholders is to inform an API of state for internal logic. The fact that this state is not consistent or predictable means that it is useless for this primary use case. 

 

I understand that the recommended solution is to call ZD APIs to get more predictable state values, but this does introduce another roundtrip, and again, makes the webhook placeholders useless. I just want to note here for future design decisions that this is an obvious departure from industry standards and common webhook implementations across other services.

0


This says that {ticket.created_at} should not include the year if the ticket was created in the current year. I just used this placeholder for a ticket that was created today (1/14/2025), and the output did include the year. I also tested for a ticket created yesterday and it still included the year (example below). The “Don't include the year if the year = current year” feature seems to be broken. 

0


Please sign in to leave a comment.