Zendesk has a myriad features you can use to create powerful automations and flows for your tickets without resorting to external scripts or tools like Zapier, server-less functions or other tools.

The most basic of those are Triggers and Automations which allow you to update tickets based on changes or time. You can for example set a ticket to open if it's been on pending for more than 3 days, you can increase the priority of all tickets that contain the word Fire 🔥 or open a ticket when its due. These are all pretty basic examples of how you can leverage those two business rule types to change ticket data.

But sometimes you want to do more complex changes. You want to copy data from one ticket field to another, want to use data from a users' organisation to update data in their tickets or similar flows.

For these more complex scenario's we can leverage Webhooks in Zendesk to have Zendesk itself execute API calls on itself to make changes to your tickets. 

This article will give you some examples on what can be accomplishes by leveraging Zendesk Webhooks and the Zendesk API.

Webhooks

Webhooks are a feature available in Zendesk normally used to alert external platforms of actions that happened within Zendesk.

You can get notified for Zendesk Events: an article get published, a user is created, a custom object's expiration date has passed,...
Or you can use triggers and automations to send out alerts based on specific ticket conditions like "a vip ticket has been created", or "a ticket has been on hold for 3 days".

When those conditions are met the webhook will send a payload to a specific API endpoint or website. You can for example create a webhook that adds an alert to Slack whenever an article is added to your Help Center.

For a full overview of what's possible with Webhooks, take a look at these articles:

Webhooks - Internal Note

Internal Note

Calling the Zendesk API

As mentioned above, one of the most powerful and hidden webhook features is their ability to call the Zendesk API from within a webhook. Or as I call it: leveraging the power of /api/v2/tickets/{{ticket.id}}.json.

I've written about it in the past in passing in a l couple of articles already:

1. Return to Sender - Reassign Zendesk Tickets back to the original agent - This article mentions reusing an update ticket webhook and provides details on setting up a webhook for user and organisation events.
2. Update a requester name via webhooks and custom fields - This article details the setup of a webhook that updates the ticket requester's name using a custom field and a trigger for created tickets that calls the webhook for web form tickets.
3. Zendesk Custom Objects - Part 4: End-User and Forms - This article explains setting up a webhook to fill in a Lookup field for end-users by having them fill in an Intermediate Field.
4. Automatically link incidents and problems in Zendesk - This article outlines the creation of a trigger that utilises a webhook to update a ticket based on specific conditions.

In each of these scenarios we use the Zendesk ticket API to update tickets based on conditions in triggers and automations.

Setting up the webhook

Before we can get started with some examples, we need to setup the webhook itself. We only need to setup this webhook once, and we can use it across all the triggers and automations that require it.

To setup the webhook go to Admin Panel > Apps and Integrations > Webhooks and add a new webhook.

Conditions

• Name: Update Ticket
• Endpoint URL: https://domain.zendesk.com/api/v2/{ticket.id}}.json
• Type: POST
• Authentication: Basic
  • admin@domain.com/token
  • A Zendesk API Token

Once configured the system will run a test. You'll need to enter an existing ticket ID. No worries, no actual data will be updated!

Example scenarios

Migrate Field Data

Zendesk Messaging and the Zendesk Bot allow for asking customers for information during a flow, or before a ticket is submitted to an agent.

So in a scenario where you want customers to contact you, you might want them to enter a Membership number during the flow. Chances are you already had such a ticket field setup for your Help Center forms.

But now you run into an issue. The existing Membership ID field was a numeric field, but Messaging only supports Text Fields in its Answers. Which means you need to create a new Membership Ticket Field of type Text which leaves you with two Membership Fields.

The best solution here is to deactivate the existing Membership numeric field, and also add the text field to your forms so that you have one field to work from, or one field to use in reporting.

To make such a migration, it would be nice if you could migrate all memberships entered into the numeric field to the new text field for all active tickets so that agents don't loose this information while you're making the changes. This is where the webhook comes in!

Solution

To migrate all the existing data over we can use an Automation combined with our webhook.

The webhook has the following conditions:

• Ticket status is less than solved (since we only want to update active tickets)
• Ticket tags do not include updated_membership . We set this tag upon update so we know which once we already updated.

We then have two actions:

• Set tags to updated_membership
• Notify Webhook: Update Ticket (the one we created earlier).

Our webhook has the following payload:

{
  "ticket": {
    "custom_fields": [
      {
        "id": 123456789,
        "value": "{{ticket.ticket.ticket_field_987654321}}"
      },
      {
        "id": 987654321,
        "value": null
      }
    ]
  }
}

Once we create our automation it will start migrating data up to 1000 tickets every hour. So depending on your backlog, your entire ticket queue will be updated quickly. Once all tickets are processed you can disable the automation, deactivate the old numeric field, and enable the new text field in your forms.

Alternative uses

This combination of automations and webhooks is perfect to process large amount of tickets while your refactoring an existing Zendesk instance and want to combine or update existing fields without losing data. I've used it for combining category fields, moving from text fields to the new lookup fields, or similar flows.

Just note that this will only work on tickets that are not closed since these are read-only so your old tickets will remain as is.

Account Manager

Lookup Fields in Zendesk can be used to link different objects together. 

One popular use case for Sales oriented Zendesk environments is adding an Account Manager field to Organisations, that links to an Agent or Light Agent in your instance. This way you can quickly reference that John McClane is managing the Nagasaki account.

When looking at a ticket for that organisation, you might want to use a macro or trigger to automatically add John as a follower to the ticket when escalation is needed. The problem is that although you can reference a tickets' organisation in triggers, you cannot (yet) access nested lookup fields in triggers. So the Account Manager field on the organisation level is not accessible in your trigger.

Solution

This is yet again a scenario where our webhook comes into play:

What we'll do is create a new Ticket Field Account Manager. This field is a Lookup Field that links to user objects.

We can then create a trigger with the following conditions:

• Ticket is created
• Organisation > Account Manager is present

We then add an action to notify our Update Ticket webhook with the following payload:

{
  "ticket": {
    "custom_fields": [
      {
        "id": 1234567890,
        "value": {{ticket.organization.custom_fields.account_manager.id}}
      }
    ]
  }
}

Here, 123456789 is the ID of our Account Manager Ticket field. Note that by using the .id suffix for the {{ticket.organization.customfields}} placeholder will return the ID of the account manager linked to the organisation, instead of their name.

Now, whenever a ticket is created for whose organisation an account manager is set, we'll update the ticket to set the account manager field on the ticket. We can then leverage that value for escalations as Follower, Side Conversation e.a.

Alternative uses

You can use this flow to set any kind of lookup field. So if you've linked an asset to a ticket, you can fill in a location field on the ticket for routing to the right team, or fill in a supplier field for automatically escalation the work to them via side conversation.

Or, instead of setting a custom field, you can also set the ticket assignee to the account manager linked to the organisation via:

{
  "ticket": {
    "assignee": {{ticket.organization.custom_fields.account_manager.id}}
  }
}

Similar use cases

The scenarios above focus on updating the current ticket with information from organisations, users or other ticket fields.

Updating users

We can leverage the same concept to update a ticket requester instead by creating a new Update Requester webhook that points to api/v2/users/{{ticket.requester.id}}.json.

You can leverage this webhook for a couple of scenarios:

Zendesk doesn't natively allow you to ask for a phone number in the same way we can ask for a name or email address. So most users resort to creating a ticket field Phone Number to ask for that information. 

The issue here is that the data lives on the ticket object, where it should live on the user object so the profile information is always available across tickets.
By creating a trigger that notifies the Update Requester webhook and pushes the following payload, we can push the Phone Number stored in ticket field 123456 to the users' profile

{
  "user": {
    "phone": "{{ticket.ticket_fields_123456}}"
  }
}

Or similar, if we want to store the membership number from our first scenario at the start of this article on the user profile, we can use the same webhook and push the following payload. (Assuming we have a user field called "membership"

{
  "user": {
    "user_fields": {
      "membership": "{{ticket.ticket_fields_123456789}}"
    }
  }
}

Help Center Escalation

To wrap this up with one final flow I'm tinkering with is a way to turn good comments into draft articles for your Help Center:

• Have a macro that tags a ticket with "worthy of an article"
• Have a webhook that calls /api/v2/help_center/en-us/sections/123456789/articles
• Post the last comment of the article via {{ticket.latest_comment_formatted}} as part of the article payload.

{
  "article": {
    "title": "Porposed article - {{ticket.subject}}",
    "body": "{{ticket.latest_comment_formatted}}",
    "locale": "en-us",
    "draft": true
  }
}

This will create a new draft article, which will get picked up in your Zendesk Guide knowledge base management. You then use the new Zendesk Guide AI features to expand that comment into an article.

Conclusion

As you've seen above, no matter if it's automation copying data between fields in bulk via automations, or linking user and organisation data to tickets and users, you can leverage the webhooks to make these complex flows possible without resorting to external resources.

How are you going to leverage this new superpower?