Die Zendesk-Plattform: Trigger, Webhooks und Custom Objects verstehen
Bevor man in Zendesk irgendetwas automatisiert, lohnt sich ein Blick auf den Werkzeugkasten selbst. Fünf Bausteine tauchen immer wieder auf: triggers, automations, webhooks, custom fields und custom objects. Jeder macht eine Sache gut. Die meisten Konfigurationsfehler entstehen nicht, weil ein Baustein schlecht ist, sondern weil der falsche gewählt wurde: ein trigger, wo eine automation hingehört, ein custom field, wo ein custom object gebraucht wird. Diese Seite sortiert die Grundlagen.
Die Bausteine
| Baustein | Wann einsetzen |
|---|---|
| triggers | Sofortige Reaktion auf ein Ereignis am Ticket, wenn es erstellt oder aktualisiert wird. |
| automations | Reaktion nach Zeitablauf: «X Stunden ohne Antwort». Läuft stündlich, nicht sofort. |
| webhooks | Etwas ausserhalb von Zendesk anstossen: ein HTTP-Request an ein Fremdsystem. |
| custom fields | Eine Zusatzangabe direkt an Ticket, User oder Organisation hängen. |
| custom objects | Eine eigene Datentabelle für Dinge, die kein Ticket sind: Vertrag, Gerät, Fahrzeug. |
public/werkstatt/bauplaene/plattform-grundlagen/objects-and-rules.png
triggers, automations, webhooks: das Regelwerk
Die ersten drei gehören zusammen; Zendesk nennt sie business rules. Der Unterschied zwischen triggers und automations ist der zwischen Ereignis und Zeit.
Ein trigger ist ereignisbasiert: Er prüft seine Bedingungen jedes Mal, wenn ein Ticket erstellt oder aktualisiert wird, und handelt sofort, wenn sie zutreffen. Typische Fälle: eingehende Tickets nach Sprache oder Produkt in die richtige Gruppe routen, bei «dringend» eine Benachrichtigung auslösen, eine Bestätigungsmail beim Erstellen senden. Die Reihenfolge zählt: triggers laufen von oben nach unten durch ihre Kategorien, und die Aktion eines triggers kann die Bedingung des nächsten erfüllen. So entstehen gewollte Ketten, aber auch ungewollte Schleifen. Zendesk fängt Endlosschleifen ab; die Reihenfolge und die Kategorien sauber zu halten bleibt deine Aufgabe.
Eine automation ist zeitbasiert: Sie läuft einmal pro Stunde über alle nicht geschlossenen Tickets und greift bei einer erfüllten Zeitbedingung: «seit 24 Stunden keine Reaktion», «4 Stunden nach Lösung schliessen». Weil sie wiederholt läuft, braucht jede automation eine Selbstbegrenzung: entweder eine Aktion, die eine ihrer eigenen Bedingungen aufhebt, oder eine Bedingung, die nur einmal wahr sein kann. Sonst feuert sie stündlich weiter. Faustregel: Soll sofort etwas passieren → trigger. Soll nach Ablauf von Zeit etwas passieren → automation.
Ein webhook ist kein Auslöser, sondern ein Ausgang: Er schickt einen HTTP-Request an eine URL ausserhalb von Zendesk. Zwei Wege führen hin: man abonniert Zendesk-Events (User gelöscht, Organisation geändert; Zendesk sendet dann POST mit JSON), oder man hängt den webhook über die Aktion «Notify webhook» an einen trigger oder eine automation. So verbindet sich das Regelwerk mit der Aussenwelt: Slack-Meldung bei einem kritischen Ticket, Ticketdaten an ein Fremdsystem weiterreichen. Wie weit man Webhooks im Bot-Kontext treiben kann und wo das Produkt diese Handarbeit heute ablöst, steht in Action Flows und im ZIS-Umweg.
Wer einen webhook aufsetzt, richtet zugleich seine Absicherung ein. Zendesk spricht nur über HTTPS und kennt drei Auth-Arten: API-Key, Basic-Auth und Bearer-Token. Zur Prüfung auf der Gegenseite signiert Zendesk jeden Request mit einem Signing Secret per HMAC-SHA256; der Empfänger rechnet die Signatur nach und weist Fremdaufrufe ab. Scheitert ein Aufruf, wiederholt Zendesk ihn bis zu fünfmal und bricht nach zwölf Sekunden Wartezeit ab. Häufen sich die Fehler, schaltet ein Circuit-Breaker den webhook vorübergehend ab.
Und ein Schweizer Punkt: Ein webhook leitet Ticketdaten aus Zendesk heraus. Stehen Personendaten darin, ist das eine Bekanntgabe an Dritte, die das revidierte Datenschutzgesetz (revDSG) mitregelt. Kläre Ziel und Zweck der Ausleitung, bevor der erste Request rausgeht.
custom fields und custom objects: wo Daten wohnen
Die letzten beiden speichern Daten, aber unterschiedlich.
custom fields hängen direkt an einem Standardobjekt: Ticket, User, Organisation (und an custom objects selbst). Sie gibt es in vielen Typen: Textzeile, Dropdown, Checkbox, Datum und mehr. Man nimmt sie für eine Eigenschaft dieses einen Tickets oder Users: Vertragsnummer, Kategorie, Rückrufwunsch. Ticket fields haben zudem einen Vorzug, der oft übersehen wird: Nach dem Schliessen sind sie unveränderlich, und jede Änderung steht im Audit-Trail des Tickets. Das zählt, wo Nachvollziehbarkeit gefragt ist.
custom objects sind ganze Tabellen: jedes Feld eine Spalte, jeder Datensatz eine Zeile. Sie passen für Dinge, die kein Ticket sind und für sich existieren: ein Produkt, ein Vertrag, ein Gerät, ein Fahrzeug, ein Termin. Sie lassen sich über lookup-Relationen mit Tickets, Usern, Organisationen und anderen custom objects verknüpfen und stehen in triggers und Explore zur Verfügung. Für Automatisierung auf der Tabelle selbst gibt es zusätzlich object triggers als eigene Regelart: Sie feuern, wenn ein Record angelegt oder geändert wird (bis zu 100 pro Objekt, je bis zu 50 Bedingungen). Das ist das Gegenstück zu den ticket-basierten triggers weiter oben. Anders als ticket fields bringen custom objects aber keine Unveränderlichkeit mit.
Sie sind zudem an den Plan gebunden: von 3 Objekttypen im Team-Plan über 5 im Growth- und 30 im Professional- bis zu 50 im Enterprise-Plan. Kontoweit kommen harte Grenzen dazu: bis zu 50 Millionen Records, 32 KB pro Record und 100 Felder pro Objekt. Diese Kontingente passt Zendesk an; ein Blick in die aktuelle Plan-Übersicht vor dem Aufsetzen lohnt sich.
Die Entscheidung ist damit meistens einfach: Gehört die Angabe zu genau diesem Ticket → custom field. Ist es ein eigenständiges Ding mit vielen Datensätzen → custom object. Wer das von Anfang an sauber trennt, spart sich später den mühsamsten aller Umbauten: den an den Daten selbst.