Zapier and Zendesk

Zapier splits everything into triggers, which start a Zap, and actions, which do something. The Zendesk app carries both.

On the trigger side you get the events you would expect: a new ticket, a ticket that changed, a new user, a new organization. Some of these poll rather than fire instantly, which matters more than it sounds. A polling trigger checks on an interval set by your Zapier plan, so "instant" can mean a couple of minutes on a cheap plan. Check the current trigger list on the app page before you design around a specific one, because Zapier revises these without much fanfare.

On the action side you can create a ticket, update one, look one up, and create or update a user. There are also search actions, which are the ones people forget and then rebuild badly. A search step lets you find a ticket or a user by a field and pass the result into the next step instead of guessing.

Auth is the standard OAuth handshake against your subdomain, or an API token. Use a dedicated integration account rather than a real agent, because you will eventually want to exclude its updates from a trigger and you cannot do that cleanly if the account also answers tickets.

Three situations, honestly.

The other tool is small. Nobody is building an official Zendesk app for a 400-customer SaaS, but it probably has a Zapier listing, and that is the whole argument.

You need logic between the two systems. Filters, paths, a Formatter step that reshapes a date, a lookup table that turns a product code into a group. Native integrations are usually a straight field mapping, and the moment you need an "only if" you are writing code.

You need it today. A Zap takes twenty minutes. A webhook plus a receiver plus a deploy pipeline takes a week, and half the time the requirement evaporates before you finish.

Name every Zap so the name says what it does and where it goes. Six months of unnamed Zaps is how teams end up afraid to turn anything off.

Put the filter as early as possible, ideally step two. Every task after the filter costs money and every task before it does too, so filtering early is both cheaper and clearer.

Check the Zap history weekly for a fortnight after launch. Most Zaps fail quietly on an edge case in the first month, usually a null field, and then never again.

And write down who owns it. An orphaned Zap running against a departed employee OAuth token is the classic way an integration dies on a Tuesday for no visible reason.