- Sending an SMS text message when an urgent ticket has been unattended for more than 48 hours
- Sending a notification to a Twitter stream when a new urgent ticket is created
- Creating a Salesforce case from a ticket
Those are just a few examples. See Setting up a target below for more information about the targets available. Targets are used in automation and trigger actions. First you configure a target and then you specify the target using the Notify target action.
Setting up a target
Target | Description |
---|---|
Basecamp |
Using the Basecamp target, you can push ticket updates to a project as:
You need to enable API access in your Basecamp account to use this target. For information about setting up Basecamp, see Setting up and using the Basecamp target. |
Campfire | Send notifications to a Campfire chat room. |
Clickatell | Use this target to send SMS messages using your Clickatell account.
Follow the steps in Clickatell HTTP API Guide to setup the account, add a HTTP connection and obtain an API ID. |
Send emails to specific addresses. You can define the action in a trigger or automation.
Note: If the target email address is an external Support address on another Support account with whom you have ticket sharing agreements, the email notification is rejected by the target email address. A ticket will not be created. This happens in order to avoid an email loop. If you need to share support requests with another Support account, use the ticket sharing feature instead.
|
|
Get Satisfaction | Post public comments to Get Satisfaction topics for tickets created using the Zendesk moderator tool in Get Satisfaction.
By creating this target, the necessary triggers and views and also add a useful widget in the home and ticket pages (you can remove those widgets if you don't need them) will automatically be created. |
HTTP | Pass information in the request body of HTTP requests to third-party services and REST APIs that accept JSON, XML, or form-encoded content. See Creating webhooks using the HTTP target. |
Pivotal Tracker | Create stories in Pivotal Tracker from a Zendesk Support ticket to easily prioritize support issues in your project backlog.
The Pivotal Tracker target sends the Zendesk Support ticket ID to Pivotal Tracker when creating a new story. If you have enabled Pivotal Tracker's native Zendesk integration in the target Tracker project, a link back to the Zendesk Support ticket is created in the new story. |
Salesforce | Create a Salesforce case from a Zendesk Support ticket.
When you set up this target, an example trigger is automatically created for you. |
SugarCRM | Push ticket data to a SugarCRM case. |
Twilio | Use this target to send SMS messages to a mobile phone using your Twilio account. |
Send notifications to a Twitter stream.
Note: Make sure that you protect your twitter stream if you don't want notifications to be readable by the general public.
|
|
URL | Pass URL parameters to any URL. You can use placeholders as values. Example: www.some-address.com?customer_name={{ticket.requester.name}}. Set up a script on your server to receive the request, and then you can do just about anything from there. See also the HTTP target above. To troubleshoot problems with the target, see Get information about HTTP and URL targets that aren't working.
Note: We don't recommend using URL/HTTP targets to update tickets in Zendesk Support, which can result in multiple issues. Use for external targets only.
|
Yammer | Send notifications to a Yammer stream.
Follow the steps in this Yammer Target Guide to create a client application in Yammer and authorize this target to use the Yammer API. For more information, see Notifying your Yammer feed. |
- Click the Admin icon (
) in the sidebar, then select Extensions.
- Click the Targets tab.
- Select Add target.
- All of the target options are listed. Select the type of target and enter the required target information (which varies from target to target).
- Select Create Target from the drop-down list at the bottom of the page. If you want to test the target before adding it, select Test Target.
- Click the Submit button.
Once you've set up targets, you can edit, delete, and deactivate and reactivate them. See Managing external targets.
Using targets in automations and triggers
Once you've set up targets, you can use them in automations and triggers. Here's an example of a trigger that notifies a Twitter account when an urgent ticket is created:
Since you're interacting with external targets, there may be a delay between when a trigger or automation runs and when you'll see the results in the external target (in the example above, that would be your Twitter home page or stream).
You can enter up to 8192 characters in the Message field of a Notify target action.
Avoiding timeout errors
If a timeout error is received within 10 seconds of a request being made, Zendesk retries the request. After 21 consecutive failed attempts to retry the request, Zendesk deactivates the target. You'll need to reactivate the target before you can use it again.
Zendesk admins receive a notification when a target is automatically deactivated. They don't receive a notification when a target is manually deleted or deactivated.
- The message body in the trigger or target page is blank.
- There's a problem with the receiving server.
47 Comments
Adding slack would be nice to notify teams with certain triggers.
Hi, we are currently implementing triggers to call back to our internal system to log ticket details. Our internal back end system is offline overnight so cannot accept updates from the trigger during those hours.
the docs above state "Zendesk attempts to send the notification 10 times. If all attempts fail, the target is deactivated" - what is the timeframe / strategy used for the retries? Can this be modified? can triggers be scheduled only to fire during a given time frame?
thanks, Colin
Hi Colin,
The triggers fire in quick succession if they fail, and the functionality in this regard cannot be modified. Triggers can be set to fire after a specific event, so if your agents only made the event which triggered the notificiation during those hours, then the triggers would only fire during those hours. Lastly, these trigger conditions may interest you to control the time: Ticket: Within Business Hours? and Ticket Schedule: Is?. These will use the business hours set in the account. Please note that you must have business hours available in your plan to use these conditions.
Sincerely,
James Peterson
Thanks for the speedy reply James. I've looked at those trigger conditions, and presumably that would stop the trigger firing outside of business hours (or the defined schedule)?
Would there then be another way to pick up those ticket updates that were missed? Automations or is there some part of the web API that would allow us to poll for events that had not fired the trigger?
I would perhaps use an automation with the same business hours logic. The automation will be attempted every hour and with a condition you can make this not execute outside of business hours.
Note that you will be using a tag to nullify the automation conditions so you may need to clear the rag at sone stage also.
Hi Colin,
Thinking about this a bit more, you could try using the triggers, and then tag the tickets if it is outside of business hours. Then, you could use an automation like Colin suggested to catch those tickets, checking for the tag which indicates the ticket update was missed.
Cheers!
James, Colin, thanks for the info. We are checking with the business owners about how critical this is. I can see we can make it pretty reliable, but there will always be the possibility to miss events. If they say they need them all we'll have to revert to a pull model using API.
Is there a plan to provide this support for Help Centre/Community posts?
I'm trying to keep up-to-date with posts and updates on the Help Centre and community by posting updates to Slack.
Thanks!
If you are on Office 365, you can set up Inbox Rules to Forward to Text Message. So what we do to send SMS messages is:
Hi,
> Zendesk Support attempts to send the notification 21 times. If all attempts fail, the target is deactivated.
I don’t understand the meaning of this sentence. It seems very vague.
What do you send 21 times? What does it mean "the notification" ?
You retry sending the same request 21 times , or 21 is a threshold of sum of failed requests ?
And, what does “If all attempts fail” mean? Does failure involve HTTP 4xx response ? HTTP 5xx response? or other failures?
Daisuke,
The terminology 'notify target' is used in triggers to select a target. "Notification" refers to the outgoing http request which is configured in the target. 21 is the threshold for consecutive target failures. If 21 consecutive requests are sent and the returned http response code is anything outside of the 2xx range the target will be deactivated and the owner will be notified of the deactivation.
Hopefully this helps answer your questions. Let me know if you have any follow-ups. Thanks!
Hi Daniel,
Your answer is really helpful for us.
Thank you very much!
Hi,
Is it possible to have one target (email)with a set of different email addresses? So that I should not create 5 targets but just one with 5 addresses in it?
or, is there already a solution like that one?
I was thinking that maybe MailChimp but so far that is not working for us.
Thanks!
Hi Gabriela,
Did you find any solution to your problem? I've tried semi-colon, commas blank space to separate the email addresses but seems like I cannot do this.
Thanks,
Hi Omair and Gabriela!
At the moment we do not support multiple address in a single target. These need to be created in separate targets.
I hope this helps!
In the case of a target deactivation please consider sending the notification to all admins, not just the owner! We've had targets break and not be caught for days because the owner missed an email! All admins can access the extensions section, thus all admins can fix the problem!
Thanks!
Daniel Pawluk , you should write that information in the guide. Thanks!
Our external integration was deactivated. When I try to "Test Target" I get an error message but don't know how to troubleshoot it. The error message is:
Error during transmission: HTTP client call failed
Hey Don,
We've had this happen before - targets are deactivated when they experience 21 consecutive failures.
You can try to find out why they failed in the API settings of your account, under API->Target Failures. There might be more to the error there.
Also make sure you're not using a transient service as the endpoint for your target, like requestb.in They will periodically deactivate over time and return failures.
Otherwise, my best guess would be to double check your credentials and ensure you can reach the target via another source (such as your browser or a direct API/cURL call)
Dan, thanks!! This was exactly what I needed.
HeyO Dan Ross (et al),
Just a heads-up - the automatic deactivation of targets should now notify all admins as requested. This is mentioned in the above article, but I wanted to be sure you'd seen it!
!!!
Thanks very much Dwight, that's great news!
I have one question about the tries that is made. If my target is automaticlly deactivated cuz my requests failed, when I activate it again, my failed requests will try again to send this data?
I'm asking that because yesterday my Lambda function which receive all webhook requests failed, and when I looked at the Target Failures page, I could see all the errors which had 21 tries, after I fixed the function and reactivate the Lambda, all errors disappeared and I don't know it was sended again or just deleted.
Thanks! :)
Hi Renan,
If a target making webhook requests has failed, the requests will not be automatically resent. It only attempts those requests once. In order to notify that other system, you would have to update the ticket again such that the target fires again.
Hi Dwight!
Is there a better page where I can see all the failed requests?
On this one: https://xxx.zendesk.com/agent/admin/api/target_failures I can see only the last ones...
Thank you!
Hi, I have a question on automatically disabled targets.
Is there a quicker way to find out which trigger to audit that made a particular target become "disabled"?
We are trying to identifying why this target failed, but we have hundreds of triggers so I thought I'd ask if there was a less manual way to find what trigger this target was used for.
Our webhook server is frequently offline for several hours or even days, during which time it's acceptable that we miss out on webhooks.
When the server comes back online, I'd like it to start receiving webhooks again without having to get an admin to re-enable them in Zendesk.
Is it possible to disable the "retry 21 times and then disable the target" behaviour? I don't mind if it never retries a failed webhook.
HeyO Grant,
Apologies for the confusion - this passage is somewhat misleading:
Zendesk Support attempts to send the notification 21 times. If all attempts fail, the target is deactivated.
The target does not make multiple attempts for a single request, but rather disables automatically after 21 consecutive failures on 21 different requests. I will reach out to our documentation folks to see about revising the above lines to be clearer.
To address your question, I don't believe there is currently a way to prevent targets from automatically de-activating based on these failures, but that's an interesting feature we could look into adding. In looking through our Product Feedback Forums I wasn't able to find an existing request similar to what you're after. I'd recommend posting therein so that other folks can vote in support of your idea to get it additional attention from our Product Managers.
Thanks @Dwight Bussman. I've added feedback as you suggested.
Thanks also for clarifying the behaviour of the deactivation process.
Hi guys,
Is there any available function that we can use in the POST body within a Target? I mean, I need to pass some ticket fields through the target but I need to split few values using typicall substring() function, I cannot pass the values as they are.
As far as I know, there's no option to use anything like this, but just wanted to double-check. Thanks!!
Please sign in to leave a comment.