Change Ticket Requester via Automation

A common use case for many Zendesk administrators is the need to automate changing the requester of a ticket based on a set of conditions.  Currently, neither triggers nor automations provide an action statement to change the requester; however, by leveraging Zendesk webhooks one can in fact build a workflow to support this requirement, which can be used to change ticket requester via trigger or via automation.  This article hopes to provide a relatively straightforward and easy set up guide for this workflow, divided into the following parts:

1. Determining workflow requirements
2. Find the requester ID
3. Creating the webhook
4. Creating the automation(s)

Part 1: Determining workflow requirements

The first step is to determine the specific business requirements.  There are countless variations, but the common denominator is that the ticket requester should be updated via business rule. The main differences are in the conditions to determine when that should happen, such as the brand that a ticket is associated with, or the amount of time since the ticket was solved, among others.

As a sample, we will work with the case that a ticket is submitted on behalf of a customer, and 5 days after the ticket is solved it the requester should be changed to an internal team.

Part 2: Find the Requester ID

Now that we have mapped out our use case, the next step is to find the identifiers needed to update the requester of a Zendesk ticket.  To find the requester's user ID, you can search for the user and load the profile page.  Then look for the ID in the URL of that page.  The URL will look like https://d3v-easternlogic.zendesk.com/agent/users/360010730954/requested_tickets, with the ID in this case being 360010730954.

Please see the screenshot below for reference:

Part 3: Create the webhook

Now that there is an ID for the requester, the next step will be to create the webhook. For inexperienced system admins, this can be one of the more difficult parts of the set up, but just follow the steps carefully and it should be possible to create it without much trouble.

First, go to to the admin panel of Zendesk, and then either search for Webhook in the top left search bar, or expand the Apps and integrations section at the bottom, and choose Webhooks under the Actions and webhooks heading.

The webhooks page will be located at a URL https://{subdomain}.zendesk.com/admin/apps-integrations/actions-webhooks/webhooks, so you can also change the {subdomain} part of this URL and navigate directly to the page.

Next, click on the Create webhook button in the upper right corner of the webhook page.

Then choose 'Trigger or automation' as the way to connect for Step 1 and then click the Next button in the lower right corner.

In Step 2, you'll need to add the details specific to your own account. First, give a name to the webhook, such as Update Ticket as the webhook will be updating a user profile.

Optionally, fill in a description to help provide context about how you are using the webhook.

For the Endpoint URL, you'll need to use the following https://{subdomain}.zendesk.com/api/v2/tickets/{{ticket.id}}.json, with the {subdomain} portion filled in with your own subdomain. So for us, we use https://d3v-easternlogic.zendesk.com/api/v2/tickets/{{ticket.id}}.json. The {{ticket.id}} portion is a Zendesk placeholder which will automatically substitute the placeholder with ID of the user that requests the ticket.

Under Request method use PUT.

Request Format should be JSON which is the default value.

For Authentication, you should use the Basic authentication option. You'll need to provide a username and password. For the username, we strongly recommend using a system account profile rather than your own profile username. We have seen many times where a user account is removed after leaving the organization, and then all of the integrations set up with that user account break, and the incoming admin has no idea what broke or how to fix it. For our case, we will use the email address system.user@easternlogic.hk. In addition, you'll need to add a /token after the email address in order to use an API token, which is the recommended practice. So it will end up looking like this: system.user@easternlogic.hk/token. Alternatively, a password can be used for authentication, but we do not recommend as passwords are subject to change and can thus break the integration at a later time and create a difficult troubleshooting situation.

In the Password field, you'll need to add an API token. I recommend creating a new token for this integration. You can read more about Zendesk's API tokens here, or you can navigate to the Zendesk API page underneath the Apps and Integrations section > APIs heading of the admin page. The URL will look like https://{subdomain}.zendesk.com/admin/apps-integrations/apis/zendesk-api/settings/tokens, with the {subdomain} portion being replaced by your own account subdomain.

In the API page, click on Add API token to create a new API token to use with this integration.

Next, provide a description for your API token, such as Update Ticket Webhook. Then copy your token and paste it into the password field back in the create webhook page.

Once that's done, you should be ready to save your webhook. So go ahead and click the create webhook button at the bottom of the page.

The last page will be Step 3: Connect webhook. You can go ahead and click on Finish setup in the bottom right corner right away, and we will then proceed to create a trigger to fire the webhook.

Part 4: Creating the automation(s)

For part 4, we will be creating a new automation that will be using the webhook as an action to actually make the update to the ticket's requester.  First, head over to the automations page.  You can do a search for automation in the search bar, or manually navigate to it under the Objects and rules Section > Business rules heading. The URL for triggers will be under https://{subdomain}.zendesk.com/admin/objects-rules/rules/automations, with {subdomain} being your account subdomain.

From here, click on Add automation.

You'll need to first provide a name for the new automation, such as Change Ticket Requester. 

Next, you'll need to set the conditions for your automation.  If you're unfamiliar with automation conditions, we recommend first taking a look at Zendesk's guide to automations here.

For our conditions, we will be firing after the ticket has been solved for 5 days (120 hours), belongs to a specific brand, and also contains the tag requester:360010730954.   See screenshot below for reference:

In our case, we only want the automation to fire if all four of these conditions are met, so they must be created under the All section.  Creating conditions under the Any section has a different outcome and can cause confusion for many new admins.  For more information on All vs Any, please see this FAQ on Zendesk's Help Centre.

That being said, this automation can be modified to fit your own requirements, either by using different conditions in the All section, by adding conditions to the any section, or even by cloning the automation and using a new set of conditions.

Lastly, we will need to configure the actions section of the automation.  Click the Add action button, choose Notify by > Active webhook under the category, and choose the recently created Update Ticket Webhook as the value.  You'll see the Endpoint URL, Description, and Method information appear below, as well as a place to input the payload.  This payload will need to follow a specific JSON format, which you can copy from below.  Make sure to replace the {requester_id} variable with the User ID found in Step 2.

{
  "ticket": {
    "requester_id": {requester_id}
  }
}

The full automation set up is shown below. Once you've set everything up, you can click on create automation and then start testing it out.**

** Please be aware, that once you save the automation it will be live, so it will start firing on any tickets that match the conditions.  We highly recommend testing it out first with a test user profile.  For testing, you may also want to change the Hours since status category solved condition to be 1 hour instead of 120, and then after confirming it is working as expected change it back to the desired time value.

Then, you can create a test ticket that meets the requirements: has the correct brand, has the tag applied to it, and has a requester different than the one specified in the automation webhook payload.  Then, set the status to solved and wait for the automation to run.

After waiting for the automation to run, you can come back and check on the ticket to make sure that the webhook fired correctly.  To do so, open up the Event Log by using the clock icon in the upper middle portion of the ticket.  Then, at or near the bottom of the log you should see an event called Message pushed to webhook and the name of the automation you created, which in our case is called Change Ticket Requester.  If you do not see this message, then you may not have configured your automation correctly, the required time may not yet have passed, or the ticket may not meet the automation conditions, among other possibilities.

If it hasn't happend already, you should see the requester of the ticket changed in short order. Because there is a slight delay from when the webhook message gets sent, and when the update is performed, you may initially see that the requester is still set as the original requester.  If you don't see an update to the requester even though the automation fired, then it may be possible that there was an issue with the webhook.  To troubleshoot this, you can go back to the Webhooks page in Zendesk, click on the webhook that you created, and then click to view the Activity log for that webhook.

In the Activity tab, you'll see a list of webhook invocations. A 200 OK means that the action was successful. If unsuccessful, you'll often see something in the 400 range.

For example, you can see that my webhook invocations both succeeded with a 200 Success response. 

Unfortunately, this guide is unable to provide troubleshooting for all possible errors or provide examples for all the different use cases that could exist for this type of workflow, but it should provide a good starting point. Please feel free to leave comments below.