The Zendesk platform: understanding triggers, webhooks and custom objects

Before you automate anything in Zendesk, it pays to look at the toolbox itself. Five building blocks show up again and again: triggers, automations, webhooks, custom fields and custom objects. Each one does a single thing well. Most configuration mistakes don’t come from a bad building block, they come from picking the wrong one: a trigger where an automation belongs, a custom field where a custom object is needed. This page sorts out the basics.

The building blocks

triggers, automations, webhooks: the rule engine

The first three belong together; Zendesk calls them business rules. The difference between triggers and automations is the difference between event and time.

A trigger is event-based: it checks its conditions every time a ticket is created or updated, and acts at once when they hold. Typical cases: routing incoming tickets to the right group by language or product, firing a notification on «urgent», sending a confirmation email on creation. Order matters: triggers run top to bottom through their categories, and one trigger’s action can satisfy the next one’s condition. That’s how deliberate chains form, but also unwanted loops. Zendesk catches infinite loops; keeping the order and the categories clean stays your job.

An automation is time-based: it runs once an hour across all non-closed tickets and kicks in when a time condition is met: «no response for 24 hours», «close 4 hours after solving». Because it runs over and over, every automation needs a way to stop itself: either an action that cancels one of its own conditions, or a condition that can only be true once. Otherwise it keeps firing every hour. Rule of thumb: something should happen right away → trigger. Something should happen after time passes → automation.

A webhook isn’t a trigger, it’s an exit: it sends an HTTP request to a URL outside Zendesk. Two paths lead there: you subscribe to Zendesk events (user deleted, organization changed; Zendesk then sends a POST with JSON), or you hang the webhook onto a trigger or automation through the «Notify webhook» action. That’s how the rule engine connects to the outside world: a Slack message on a critical ticket, ticket data handed off to another system. How far you can push webhooks in a bot context, and where the product now takes over this handwork, is in Action Flows and the ZIS detour.

Setting up a webhook means setting up its security at the same time. Zendesk speaks only over HTTPS and knows three auth types: API key, basic auth and bearer token. To let the far side verify it, Zendesk signs every request with a signing secret via HMAC-SHA256; the receiver recomputes the signature and rejects foreign calls. If a call fails, Zendesk retries it up to five times and gives up after twelve seconds of waiting. If errors pile up, a circuit breaker switches the webhook off temporarily.

And a Swiss point: a webhook routes ticket data out of Zendesk. If personal data is in there, that’s a disclosure to third parties, and the revised Data Protection Act (revDSG) has a say in it. Clarify the destination and purpose of the outflow before the first request goes out.

custom fields and custom objects: where data lives

The last two both store data, but in different ways.

custom fields attach directly to a standard object: ticket, user, organization (and to custom objects themselves). They come in many types: text line, dropdown, checkbox, date and more. You use them for a property of this one ticket or user: contract number, category, callback request. Ticket fields also carry an advantage that’s easy to miss: once the ticket is closed they’re immutable, and every change is recorded in the ticket’s audit trail. That counts wherever you need to trace what happened.

custom objects are full tables: each field a column, each record a row. They fit things that aren’t tickets and exist in their own right: a product, a contract, a device, a vehicle, an appointment. You can link them to tickets, users, organizations and other custom objects through lookup relationships, and they’re available in triggers and Explore. For automation on the table itself there are also object triggers as a rule type of their own: they fire when a record is created or changed (up to 100 per object, each with up to 50 conditions). That’s the counterpart to the ticket-based triggers above. Unlike ticket fields, though, custom objects bring no ticket immutability with them.

They’re also tied to the plan: from 3 object types on the Team plan, through 5 on Growth and 30 on Professional, up to 50 on the Enterprise plan. Account-wide, hard limits come on top: up to 50 million records, 32 KB per record and 100 fields per object. Zendesk keeps adjusting these quotas; a look at the current plan overview before you set things up is worth it.

That makes the decision easy most of the time: does the detail belong to exactly this ticket → custom field. Is it a standalone thing with many records → custom object. Draw that line cleanly from the start and you spare yourself the most tedious rebuild of all later: the one on the data itself.