Update requester
I'm trying to update the requester on open/on-hold/pending tickets for two of our customers via the API. I'm very new to doing this, though. Can that be done?
Thanks!
-
Hi Cyn! Before I share specifics on how to do this, I'd like to know more about your use case.
- Are you looking to do this as a one time thing or is this something that you want to do on a regular basis?
- If so, would it be something that you want to happen as soon as the ticket is submitted/updated/changes status/etc?
Please share any other useful into about this situation so that I can get you going in the right direction!
-
It would be a one-time thing (I hope).
The tickets are currently on hold, so I was hoping to update them and leave them in that status/
Thank you!
-
Sorry for the late reply! Since this is just going to be a one time deal, your best bet would be to use a webhook and automation which will take all of the tricky stuff out of the equation. Essentially, the webhook will do the actual work of updating the ticket's requester and the automation will tell the webhook when it needs to run.
Create a webhook
This part of the article will walk you through the webhook creation and I'll point out the specifics that you need to fill out:
- Endpoint URL (be sure to replace "yoursubdomaingoeshere" with your actual Zendesk subdomain) : https://yoursubdomaingoeshere.zendesk.com/api/v2/tickets/10144226.json
- Request method: PUT
- Request format: JSON
- Authentication: Basic Auth is probably your best bet, although I do usually recommend using an API token instead of your password. If you're not familiar with API tokens, take a look at this article.
- One thing that usually gets people caught here is that when you use an API token, you'll need to append /token to the end of your username so instead of "greg@example.com" it becomes "greg@example.com/token".
Create an automation
Same idea as with the webhook, this part of the article will walk you through the automation creation and then I'll walk through the specifics to fill out. One very important distinction with automations is that we need to include a "nullifying condition" that prevents the automation from running over and over on the ticket. One of the easiest ways to do this is to add a new tag only used for this automation (just to make sure it doesn't affect any other tickets) in the actions, while also checking for the presence of that tag in the conditions of the automation. This means that before the automation runs on the ticket, it will run fine since the tag isn't there, but since we're adding it with this action it won't be able to run again because we're excluding tickets that include this tag.
Even with the above nullifying condition, I highly recommend turning this automation off once the tickets have been successfully updated. If you don't, two years down the road someone might start using that tag by accident and then suddenly the requester is getting switched and it causes problems.
Meet all of the following conditions:
- Ticket: Organization is "name of org"
- Ticket: Tags contain none of the following
tag_that_you_choose
Meet any of the following conditions:
- Ticket: Status is Open
- Ticket: Status is Pending
- Ticket: Status is On-hold
Perform these actions:
- Notifications: Notify active webhook "select name of the webhook that you created above"
- JSON body: (replace the
requester_id
with the user you want to switch the ticket to)
{ "ticket": { "requester_id": 123456 } }
- Ticket: Add tags
tag_that_you_choose
After this, you just need to wait until the automations run at the top of the next hour and you should be all set to go. You can do this for as many organizations as you need, just make sure to do it one by one. If it's not a huge rush, I would recommend just editing the one webhook and automation with the specifics for each org so that you don't need to create a bunch of these.
As always with something like this, please ensure that this will not cause any issues with your current workflows. This is given for instructional purposes without any knowledge of your Zendesk instance, so be sure that this works for your needs and run a test with a fake ticket/user/organization to be sure that it does what you need it to do.
Let us know if you run into any questions! -
Thank you so much, Greg!
댓글을 남기려면 로그인하세요.
4 댓글