Vor Kurzem aufgerufene Suchen


Keine vor kurzem aufgerufene Suchen

Colin Piper's Avatar

Colin Piper

Beigetreten 15. Apr. 2021

·

Letzte Aktivität 01. Nov. 2021

Folge ich

0

Follower

0

Gesamtaktivitäten

73

Stimmen

3

Abonnements

32

AKTIVITÄTSÜBERSICHT

Neueste Aktivität von Colin Piper

Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Q&A - Tickets and email

I found some of my notes on using the http target:

HTTP target

Title: Update Zendesk Ticket

Url: https://domain.zendesk.com/api/v2/tickets/{{ticket.id}}.json

Method: PUT

Content Type: JSON

Basic Authentication: Enabled (use an agents login with "/token" on the end and then use the API key as the password)

 

Trigger

Set any conditions you need

Perform these actions:

Notifications: Notify target      Update Zendesk Ticket

JSON body:

{"ticket": {"recipient": "accounts@support.domain.com", "custom_fields" : [{"id":29710328, "value": true}]}}

 

Some notes:

1) In this example I not only set the Recipient value but also the value of another custom field. Just to illustrate the power

2) The email address MUST be one that is verified as a Zendesk support email address. if not then your default support address will be used. 

3) This update does not happen immediately. Therefore if you need to update the Recipient before you send an email notification (perhaps when a  ticket is created) you will need to do a little more trickery first. 

4) Updating the Recipient does NOT cause an update event on the ticket therefore you cannot then fire more triggers based upon this change. 

Kommentar anzeigen · Gepostet 01. Sept. 2016 · Colin Piper

0

Follower

1

Stimme

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Q&A - Tickets and email

I posted a tip a long while back on how to do this with a url target. ://support.zendesk.com/hc/en-us/community/posts/203464558-Setting-the-default-reply-email-address-using-a-trigger

However using a http target is far better and I know I have posted that somewhere on these forums but I cannot find it currently. The http target is so powerful and you can update anything almost using it. In this case you are updating a field called recipient.

Kommentar anzeigen · Gepostet 01. Sept. 2016 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-KommentarDiscussion - Zendesk on Suite best practices

@Ben, if I can add some clarity from a customer to customer perspective.

Automations as you say require you to nullify the conditions before they can save. This is to say that once the automation has fired, the actions must ensure that conditions cannot still be true. In the example given on this thread, it is the adding of tags that prevents this automation looping and hence nullifies the conditions. 

This use of tags therefore allows the greater than condition to be used. Using "greater than" removes the limitations if "is" that Jessie discussed where an automation may not run within each 60 minute window,

Kommentar anzeigen · Gepostet 14. Jan. 2016 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-KommentarDiscussion - Zendesk on Suite best practices

I created a custom field with the names of the people in one of my teams and this field is used to "assign" the ticket when escalated. They can create views based upon this custom field and I clear the field when it is passed back.

Kommentar anzeigen · Gepostet 01. Dez. 2015 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-KommentarDiscussion - Zendesk on Suite best practices

Hi Joseph. Always good to hear how things work internally at Zendesk. 

We escalate between support teams in a similar way. Instead of tagging the tickets I add a private comment to the ticket via a target but I can see how tagging might be bether. 

My macro for collecting information during the escalation is quite basic so I may modify it :)

Kommentar anzeigen · Gepostet 30. Nov. 2015 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Discussion - Tips and best practices from the community

Justin, your post has made me go look at my Groups as I have 13. Was that too many? After review, it is not the number that matters but those rules that you gave (no-one in more than 2 groups etc) that are the key. I have five different departments using the same Zendesk instance and although I have decided that 13 real groups is the correct number (I actually have a few more that I hide with the Assignment control app that govern things like multiple groups being able to use one view etc), your guidance helped me to confirm that things are good. 

Thanks

Kommentar anzeigen · Gepostet 03. Juli 2015 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-KommentarDiscussion - Zendesk on Suite best practices

Matthew, the answer is yes, setting a field with business rules will ignore dependencies except for permissions. So the ticket will be marked as solved. 

What I do is to run another rule ahead of this one that will invalidate the conditions of the solving rule if my dependencies are not met. For example i have an automation that sets the ticket as solved after being pending for x days. I have two variations of this automation, one that tests for a field being blank and the other does not have this test. In the first I do not set the status to solved but instead send an email to the agent. 

Kommentar anzeigen · Gepostet 11. Juni 2015 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Discussion - Tips and best practices from the community

I will revalidate this post as soon as I get a moment.

Kommentar anzeigen · Gepostet 22. Jan. 2015 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Discussion - Tips and best practices from the community

We should be careful not to mix two things up. A ticket of type "task" always could have a due date and it has long been asked for this to also include a time. Any other type of ticket historically could not have a date associated with it but now can with the recent introduction of the custom date field. 

Giving a task a date and time capability would be great but that capability may not automatically apply to custom fields.

Kommentar anzeigen · Gepostet 08. Sept. 2014 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare


Colin Piper hat einen Kommentar hinterlassen

Community-Kommentar Discussion - Tips and best practices from the community

Just a quick note to say that a change seems to have broken this. When I blank out the custom date the filed is populated with "undefined NaN, NaN" and the ticket cannot no longer be submitted. I have created a ticket with ZD so hope this will be resolved soon. I will post back.

Kommentar anzeigen · Gepostet 09. Juli 2014 · Colin Piper

0

Follower

0

Stimmen

0

Kommentare