Zum Hauptinhalt springen

Auslöser (Trigger)

Der Auslöser entscheidet, wann eine Automation startet. Wähle ihn so einfach wie möglich. Je klarer der Startpunkt, desto verlässlicher läuft die Automation.

Trigger-Arten im Überblick​

  • Events: Start bei einem bestimmten Ereignis im Space, zum Beispiel bei neuen Aufgaben oder eingehenden Inhalten.
  • Zeit: Start nach einem festen Wiederholungsmuster, zum Beispiel täglich oder wöchentlich.
  • HTTP: Start durch ein externes System oder einen externen Prozess (siehe API Referenz).
  • Tool: Start als aufrufbarer Baustein innerhalb anderer Abläufe.

Event-Trigger​

Hier legst du fest, welches Ereignis die Automation auslöst und ob du sie auf einen bestimmten Kontext eingrenzen willst.

Wenn viele ähnliche Ereignisse hintereinander auftreten können, helfen zusätzliche Einschränkungen dabei, nur die wirklich relevanten Fälle zu verarbeiten.

Wenn du im Trigger-Bereich zwischen verschiedenen Trigger-Arten oder Konfigurations-Tabs wechselst, bleiben bereits eingegebene Werte im geöffneten Dialog erhalten. So kannst du Varianten vergleichen oder kurz nachsehen, ohne deine ungespeicherten Eingaben neu erfassen zu müssen.

Welche Event-Typen für Nutzer überhaupt auswählbar sind, welche davon systemseitig existieren und wie externe Typen als external.<type> erscheinen, steht in Event-Typen für Automationen.

Standardmäßig reagiert ein Event-Trigger nur auf Ereignisse aus dem eigenen Space. Wenn du im Trigger Quell-Spaces auswählst, darf dieselbe Automation zusätzlich Events aus genau diesen anderen Spaces übernehmen. Das ist nützlich, wenn ein Consumer-Space zentrale Reaktionen für mehrere Producer-Spaces ausführen soll.

Wichtig dabei:

  • Ohne ausgewählte Quell-Spaces bleibt das Verhalten unverändert: Es zählen nur Events aus dem aktuellen Space.
  • Mit Quell-Spaces verarbeitet die Automation nur Events aus den ausgewählten Producer-Spaces.
  • Diese Auswahl entspricht technisch on.sourceSpaces und ist sinnvoll, wenn ein zentraler Space Reaktionen für mehrere andere Spaces ausführt.
  • Der Consumer-Space der Automation muss auf diese Spaces zugreifen dürfen; sonst werden deren Events nicht übernommen.
  • Im Event-Kontext und in der Oberfläche kann zusätzlich sichtbar sein, aus welchem Space das Ereignis stammt.
  • Unter Einstellungen → Ereignisse → Event Schema kannst du solche Cross-Space-Bezüge später auch gesammelt prüfen: Dort werden konsumierte Event-Typen, sourceSpaces und konsumierende Reactions aus anderen Spaces sichtbar.

Ein praktischer Spezialfall ist email.received: E-Mails an

<spaceId>@inbound.clye.ai

werden direkt in den angegebenen Space zugestellt und lösen dort automatisch das Event email.received aus. Dafür musst du nichts separat aktivieren oder konfigurieren.

Hinweis: Screenshot ist in der Quellanwendung vorhanden und wird hier nachgereicht.

Gerade bei Event-basierten Automationen ist ein sauberer Kontext wichtig. Bei Feedback-Ereignissen wird supportSpaceId heute konsistent als string | null mitgeliefert. Dadurch kannst du Bedingungen, Variablen und Folgeaktionen robuster auf den richtigen Support- oder Kontext-Space beziehen – auch in Whitelabel-Setups oder dann, wenn gerade kein eingeloggter Nutzer im Vordergrund steht.

Zeitbasierte Auslöser​

Zeitbasierte Auslöser sind gut für Routinen, Erinnerungen und regelmäßige Prüfungen. Achte darauf, dass Uhrzeit und Wiederholung wirklich zum Arbeitsalltag passen.

Hinweis: Screenshot ist in der Quellanwendung vorhanden und wird hier nachgereicht.

HTTP-Trigger​

Ein HTTP-Trigger macht eine Automation von außen aufrufbar. Das ist sinnvoll, wenn ein externes System, ein Formular, ein CRM, ein Shop oder ein eigenes Backend die Automation gezielt starten soll.

Der Trigger stellt nach dem Speichern eine eigene URL bereit. Diese URL enthält bereits einen nicht erratbaren Token. Unterstützt werden:

  • GET
  • POST
  • PUT
  • DELETE

Für die Condition, für Action-Parameter und für Automation-Code steht der Request als event.data zur Verfügung. Typisch sind:

  • event.data.method
  • event.data.body
  • event.data.query
  • event.data.headers
  • event.data.url

Die rohen Trigger-Parameter werden zusätzlich beim Start der Automation im Start-Event unter automation.run.started.data.parameters protokolliert. Das ist nützlich, wenn du einen Lauf im Nachhinein nachvollziehen oder Fehler in eingehenden Requests prüfen willst.

Beispiele:

event.data.method == "POST"
event.data.body != null && event.data.body.customerId != null
String(event.data.query.source ?? "") == "crm"

Typischer Ablauf​

  1. Automation mit Trigger-Art HTTP anlegen.
  2. Automation speichern, damit die Trigger-URL erzeugt wird.
  3. Externes System auf diese URL zeigen lassen.
  4. Mit einer Condition prüfen, ob Methode, Header oder Payload wirklich passen.
  5. Passende Aktion ausführen, zum Beispiel chat/send_message.

Beispiel: Externes System startet einen Assistenten​

Das externe System ruft die Trigger-URL per POST auf:

{
  "customerId": "C-4711",
  "ticketId": "T-9001",
  "message": "Bitte prüfe den Vorgang und formuliere eine kurze Einschätzung."
}

Die Automation kann daraus einen Chat anstoßen und die Daten in die Nachricht übernehmen.

Externe und aufrufbare Auslöser sind sinnvoll, wenn eine Automation in größere Abläufe eingebunden werden soll. Das lohnt sich meist erst, wenn der fachliche Prozess bereits klar definiert ist. Die verfügbaren Endpunkte zur externen Steuerung findest du in der API Referenz.

Wenn du statt eines generischen HTTP-Requests lieber fachliche Ereignisse aus einem externen System senden willst, nutze externe Events. Diese tauchen in Automationen als external.<type> auf; Beispiele und Einordnung findest du unter Event-Typen für Automationen.

Weiter: Bedingungen optional einschränken, danach Aktionen wählen.

Inhalt