Use a Webhook to Set Due Date Field via Trigger or Automation

One common use case for Due Date field is to automatically set the due date to X number of days in the future after ticket creation.  At this time, there is no default action available in Zendesk to set the due date field.  In order to accomplish this workflow, a webhook and trigger or automation action can be used.  A step-by-step guide to setting up the necessary parts is provided below.  The workflow can be further adjusted for alternative use cases.

1. Create the Webhook
2. Create the Trigger

Part 1: Create the Webhook

Zendesk webhooks are a powerful feature to extend the default capabilities of the platform.  Visit our Tips & Tricks section to get additional ideas on how they can be used.  Below we will create a webhook to use for the sample workflow.

First, go to the Webhooks page in the Zendesk Admin panel, underneath the Apps and Integrations section > Actions and webhooks.  From that page, click the Create webhook button in the upper-right corner.

On the next page, you'll need to choose the Trigger or automation option for way to connect.  Then click the Next button in the lower right corner.

In step 2, you'll need to add all of the relevant details for your webhook.

1. Name - you can use something specific like `Set Due Date Field`, or something generic like `Update Ticket`.  This webhook can actually be re-used later for other ticket updates as they use a common API endpoint.
2. Description - optionally fill in this field to provide more context about what the webhook is being used for.
3. Endpoint URL, use the following, making sure to replace the {subdomain} variable with the subdomain of your own account. https://{subdomain}.zendesk.com/api/v2/users/{{ticket.id}}.json.  So for our example, the subdomain is d3v-easternlogic, rendering the full URL as https://d3v-easternlogic.zendesk.com/api/v2/users/{{ticket.id}}.json.  The {{ticket.id}} portion is a Zendesk placeholder which will dynamically insert the ID of the specific ticket being updated.
4. Request method - PUT
5. Request format - JSON
6. Authentication - Choose the Basic authentication option, and then fill in 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 2: Creating the trigger

For part 2, 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 Set Due Date on Ticket Creation.  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 Ticket Updates.

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, when the ticket does not yet have a due date set, and when the email comes into one of our support addresses called support@wholeyoatspastures.zendesk.com.  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.

We have set our due date to 7 days in the future using Liquid Markup.  You can adjust the number of days by changing the 7 in the example below to a number of your choosing.  To learn more about how the date is formatted, you can refer to this excellent guide provided by SweetHawk. *

* If you need to consider business days rather than calendar days, please refer to our companion article here.  It requires an additional set up.

{
  "ticket": {
    "due_at": "{% assign s = 7 | times: 24 | times: 60 | times: 60 %}{{ 'now' | date: '%s' | plus: s | date: '%Y-%m-%d' }}"
  }
}

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 Setting Due Date.

Then, you can create a test ticket by sending in an email with a subject line to match the condition Testing Webhook for Setting Due Date and send it in to the support address in the Received at condition.

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 Setting Due Date, 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 Set Due Date when Ticket Created.  If you do not see this message, then you may not have configured your trigger correctly or the email may not have been sent correctly, among other possibilities.

You should also see the due date of the ticket set 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 due date is still left blank. Once updated, Zendesk will show a notification in the UI if you are viewing the ticket.

If you don't see that the due date has been set, then it may be possible that there was an issue with the webhook or with the trigger payload. 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 invocation succeeded with a 200 OK.

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.