Bulk Edit Ticket Requester

A common scenario for some Zendesk admins is to change the Requester on a ticket following some external change in that user's status, such as no longer working at the company, or employees submitting tickets on behalf of end-users, or even automatically generated system emals that need a requester.  Unfortunately, the Zendesk bulk edit UI doesn't currently provide an option to change the requester; however, Zendesk does provide a powerful platform to extend default capabilities through business rules and webhooks.  In this article, we will describe a workflow that provides the possiblity to easily change the requester of a ticket via bulk edit.  The set up may be a bit complicated, but by following this guide it will be possible to create the necessary business rules and provide an easy way to make the bulk changes.*

*There are many possible variations of this workflow, and in this article we are going to describe just one use case.  As an admin, you can make further adjustments to meet your individual needs.

1. Determining workflow requirements
2. Finding requester ID
3. Creating the webhook
4. Creating the trigger(s)
5. Using the Bulk Edit Screen

Part 1: Determining workflow requirements

The first step is of course to detail the requirements of the workflow.  As mentioned, there are myriad use cases, with the common denominator being that the requester should be updated via bulk editor. The main differences are in the details of the scenario.

As a sample, we will work with the case that a particular user has left their current employment, and so the tickets they requested must be transferred to another employee at that business.

Part 2: Find the Requester ID

Now that the use case has been mapped out, the next step is to find the ID of the new ticket requester.  To find the user ID, you can search for the user Zendesk, and then look for the ID in the URL of the profile 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 ticket.

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 trigger(s)

For part 4, we will be creating a new trigger that will be using the webhook as an action to actually make the update to the requester's organization. First, head over to the triggers page. You can do a search for trigger 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/triggers, with {subdomain} being your account subdomain.

From here, click on Create Trigger.

You'll need to first provide a name for the new trigger, such as Change Ticket Requester.  You can optionally write a description to provide additional context about how the trigger is used. You'll also need to set a trigger category.  You can choose from existing trigger categories or create a new one if needed.  We'll be using an existing one called Update Ticket.

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

For our conditions, we will only be firing when the ticket is updated and if it contains the tag

In our case, we only want the trigger to fire if both 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 trigger 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 trigger and using a different set of conditions.

Next, we will need to configure the actions section of the trigger.  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}
  }
}

Lastly, we will need to add an action remove the tag to make sure the trigger doesn't cause a loop. 

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

** Please be aware, that once you save the trigger it will be live, so it will start firing on any tickets that meet the conditions.  We highly recommend testing it out first with a test user and tickets before using it on live tickets.

Part 5: Using the Bulk Edit Screen

Once the trigger and webhook set up is complete, you can run a few test tickets through the bulk edit screen.  I always use my own test profiles.  See below for example of adding the tag configured above in Part 4.

Once that update is submitted, you'll need to give Zendesk a bit of time to process it.  Then you can open up the recently updated tickets and confirm that the requester has been change.

To make sure that the trigger and webhook fired correctly, you can 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 Trigger 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 trigger correctly or the tag may not have been added correctly in the bulk editor, among other possibilities.

If you don't see this update, 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.