Support Tip: How to change the ticket Subject using a trigger
The "Email user" action allows us to set the subject of the email notification to the requester.
The ticket Subject doesn't change, though. Although there isn't a direct trigger action to modify it, we do have a way to achieve this with a "Notify target" action.
Here's how to create one.
1. Create HTTP extension
Go to Extensions, and select HTTP target:
Complete the fields as follows:
- Url: https://yoursubdomain.zendesk.com/api/v2/tickets/{{ticket.id}}.json
Make sure to replace 'yoursubdomain' with your actual subdomain - Method: PUT
- Content type: JSON
- Check Basic Authentication and user enter credentials
Must be an administrator's credentials
Let's name our extension "Admin :: Update ticket field".
2. Add target to trigger actions
After creating the extension let's create/edit our trigger, and add a Notify target action.
In the JSON body, input:
{"ticket": {"subject": "Your text goes here"}}
As shown below, we want to change the Subject to "We're here to help, [REQUESTER FIRST NAME]!" (a use case could be Offline chat tickets, for example):
This should do it.
Suggestion
Especially when the support team is the one starting the conversation (ie. not an inbound ticket sent by the customer), we can make things nicer and more coherent for customers, and ensure the same conversation can be nested by their email client.
For that to happen, the email notification subject must be the same as the ticket subject.
Therefore, we could set the Email user subject to the same expression.
Important: please take into account that a Notify target action is executed after all the other trigger actions if they all belong to the same trigger:
Depending on your use case, you might want to make sure this trigger runs before you notify the requester, so position it above the notify requester triggers.
-
In regards to getting this to work, what if we only have "Token Access" enabled for our API access? Is it possible to pass in the token as part of the authentication, or do we need to enable "Password Access" for the API?
Thanks!
-
Actually, I just answered my own question and got this to work following the basic format of authentication using the token.
username = userEmailAddress/token
password = tokenValue
I was able to successfully get this working. Hope the above helps anyone else trying this.
-
I have provided my admin credential but receiving following error while submitting Test Target in HTTP Target configuration :
{"error":"Couldn't authenticate you"}
-
Hi Azhar, have you tried changing your password, and try again? Does it also fail if you use another admin's credentials? If the problem persists I'd suggest opening a support ticket with Zendesk.
-
If you have access to the API section in your admin dashboard I would give that a try.
You can then use a UN of an admin followed by "/token" for the Username and the API token as the Password.
It would look something like, "azhar@example.com/token" "verylongapitokenforpassword"
-
Azhar - One of our agents took a look and will be responding to you shortly. However, we removed your screenshots as some of the information was a little risky to post in a public forum and we wanted to protect your account security.
-
Sorry I didn't update that Authentication issue gone after re-login. Currently looking solution for something else i.e. I was able to update the ticket subject using trigger and API call but using the same configuration, I was not able to update custom field.
Wanted to know how to update a custom field using same API call and trigger.
Expression used in JSON body of the trigger :
{"ticket": {"subject": "Subject changed for Mr. {{ticket.requester.first_name}}"}} --> It was successful
{"ticket": {"subject": "{{ticket.ticket_field_360042501834}}"}} --> It was successful
{"ticket": {"subject": "{{ticket.ticket_field_option_title_360042588434}}"}} --> It was successful
{"ticket": {"customField:custom_field_360042588434": "Chat"}} --> It was UNSUCCESSFUL
{"ticket": {"ticket_field_option_title_360042588434": "Press"}} -> It was UNSUCCESSFUL
-
Hi Azhar,
You can update ticket fields using the following syntax (https://developer.zendesk.com/rest_api/docs/support/tickets#setting-custom-field-values) -
{"ticket": {"custom_fields": [{ "id": ticket_field_id_here, "value": "some_value" }]}}
Hope this helps. Our API documentation can answer most of your API related questions, so give that a go.
-
Thanks Sergei. It worked.. :)
-
Hi Sergie,
What I noticed recently is that whenever I am trying to set custom ticket field with the above mentioned JSON expression, it is updating fine for a single word value but not working for multiple word value.
Could you please help on this?
E.g. :
{"ticket": {"custom_fields": [{ "id": 360042537054, "value": "Careers" }]}} --> Working Fine
{"ticket": {"custom_fields": [{ "id": 360042537054, "value": "Product Feedback or Questions" }]}} --> Not working fine
-
Hi, everyone!
Here I share the way I came up with the solution to, for example, remove all single quotes (') from ticket title using Liquid:
{% assign ticketTitle = ticket.title | remove:"'" %}
{
"ticket": {
"subject": "{{ ticketTitle }}"
}
}I hope it can help someone with same need I had.
Best wishes,
-
This is a not a great work around IMHO, but thanks for suggesting it. When will we get a real trigger to modify the subject of existing tickets at Update or at Create time?
- There risk is Admin Bob set this up using his account, and every time his password expires , this will *break*.
- If a service account is used for this work around, you must pay for that license to fill this feature gap (OUCH!)
- If the Trigger leveraging the Extension/Target is configured incorrectly any updates from an agent that use the trigger will come from the account tied to the credentials used for the extension/target.
-
I totally understand what you are saying.
That being said, I believe that your first point can be remedied by using a token instead of a password.
Here is a link to the documentation on that. https://developer.zendesk.com/rest_api/docs/support/introduction#api-token
This would also mean that you "could" avoid getting a service account in this case.
Again I totally understand what you are saying but I wanted to let you know that there were some workarounds to the workaround. ;)
-
I need some help with this one. we can't seem to be able to get the extension to actually go through. has there been a change to this by chance?
-
Hey Juan,
Any chance you could provide a screenshot of the target/extension you've set up so we can take a look? Feel free to omit your subdomain or any other information :)
Let me know!
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
15 Kommentare