최근 검색
최근 검색 없음

Colin Piper
가입한 날짜: 2021년 4월 15일
·
마지막 활동: 2021년 11월 01일
팔로잉
0
팔로워
0
총 활동 수
73
투표 수
3
플랜 수
32
활동 개요
배지
문서
게시물
커뮤니티 댓글
문서 댓글
활동 개요
님의 최근 활동 Colin Piper
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2016년 9월 01일에 게시됨 · Colin Piper
0
팔로워
1
투표
0
댓글
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2016년 9월 01일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
@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,
댓글 보기 · 2016년 1월 14일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2015년 12월 01일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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 :)
댓글 보기 · 2015년 11월 30일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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
댓글 보기 · 2015년 7월 03일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2015년 6월 11일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2014년 9월 08일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글
Colin Piper님이 에 댓글을 입력함
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.
댓글 보기 · 2014년 7월 09일에 게시됨 · Colin Piper
0
팔로워
0
투표 수
0
댓글