Change Ticket Organization via Trigger

A recent request we came across from a Zendesk user was to be able to change a ticket's organization via trigger or automation. At this time, neither triggers nor automations provide an action statement to change the ticket organization; however, by leveraging Zendesk webhooks one can in fact build a workflow to support this requirement.  The following article hopes to provide a relatively straightforward and easy set up guide for this workflow, divided into the following sections:

1. Determining workflow requirements
2. Finding organization identifiers
3. Creating the webhook
4. Creating the trigger(s)

Part 1: Determining workflow requirements

The first step is of course to determine the specific business requirements. We have seen a variety of different use cases, with the common denominator being that the ticket organization should be updated via trigger. The main differences are in the conditions to determine when that should happen, such as the brand that a ticket is associated with, among others.

As a sample, we will work with the above case, in which an end-user belongs to multiple organizations, and there is a strong relationship between the brand of a ticket and what should be the organization set on the ticket.  In our case, the end-user has not set the organization correctly, and so we will configure a trigger to automatically change the ticket organization based on brand.

Part 2: Find the Organization ID

Now that we have mapped out our use case, the next step is to find the identifiers needed to enable the association between a Zendesk ticket and an organization. The simplest set up is to find the ID of each organization that will be managed. To find the organization ID, you can load the organization profile in Zendesk, and then look for the ID in the URL of the organization page. The URL will look like https://d3v-easternlogic.zendesk.com/agent/organizations/360740020772/tickets, with the ID in this case being 360740020772.

Please see the screenshot below for reference:

Part 3: Create the webhook

Now that there is an ID for the organization, 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 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 Organization. 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 creating a new one called Update Ticket.

Next, you'll need to determine 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 once when the ticket is created, if the brand is Eastern Logic, and if the ticket organization is not Eastern Logic, the same as the one we searched for above.  See screenshot below for reference:

In our case, we only want the trigger to fire if all three 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.

Lastly, 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 {organization_id} variable with the Organization ID found in Step 2.

{
  "ticket": {
    "organization_id": {organization_id}
  }
}

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 new tickets that come in. We highly recommend testing it out first with an inactive email address, or by adding an additional condition, such as Subject text > Contains the following string > Testing Webhook for Changing Organization

Then, you can create a test ticket.  What I do is to select a profile that has multiple organizations associated with it, and then make sure that the Easternlogic organization selected above is not the primary organization on the profile.  Then, I send in a test email with a subject line to match the condition Testing Webhook for Changing Organization .

As an aside, I have recently switched email providers to Proton Mail. They've been good so far. If curious, you can read more over at their website here.

Once that email is sent out, you'll need to give Zendesk a minute or two to process it. Then you can find the newly created ticket by searching with the Subject line text Testing Webhook for Changing Organization, by using the ticket ID provided in the email received acknowledgement notification if one was sent, or by using your views to filter and locate the ticket.

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 Organization. If you do not see this message, then you may not have configured your trigger correctly, the email may not have been sent correctly, or the user profile may already have an organization set, among other possibilities.

If it hasn't happend already, you should see the Organization of the ticket changied 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 organization is still set as the original organization. Once updated, Zendesk will show a notification in the UI if you are viewing the ticket, and will automatically update the profile and the ticket.

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.