Zum Hauptinhalt springen

Event-Typen für Automationen

Event-basierte Automationen starten auf genau einen Event-Typ. Welche Typen du im Dialog auswählen kannst, hängt vom jeweiligen Space ab: angezeigt werden die Event-Typen, die in diesem Space bereits vorkommen und für dich sichtbar sind.

Darum ist die Liste im UI dynamisch. Die folgenden Typen sind die systemseitig definierten Event-Typen, die für Nutzer in Automationen relevant sein können. Zusätzlich können über externe Integrationen weitere Typen der Form external.<type> erscheinen.

So liest du die Liste​

  • Der Event-Trigger filtert auf event.type.
  • In Bedingungen und Action-Parametern arbeitest du typischerweise mit event.data.
  • Ein Typ taucht im Auswahlfeld meist erst dann auf, wenn es in diesem Space schon mindestens ein passendes Event gab.

Details zur Auswahl im Dialog: Auslöser (Trigger). Details zu event und event.data: Für technische Nutzer.

Workflows und Automationen​

Diese Typen sind besonders wichtig, wenn Automationen auf andere Automationen folgen sollen:

  • automation.created
  • automation.updated
  • automation.deleted
  • automation.enabled
  • automation.disabled
  • automation.reset
  • automation.run.started
  • automation.run.completed
  • automation.run.failed
  • automation.run.cancelled

Typische Nutzung:

  • Folgeautomation nach Erfolg: automation.run.completed
  • Fehlerbehandlung oder Alarmierung: automation.run.failed
  • Governance oder Audit: automation.created, automation.updated, automation.disabled

Aufgaben​

Für aufgabennahe Automationen sind diese Typen relevant:

  • task.created
  • task.updated
  • task.deleted
  • task.started
  • task.paused
  • task.progressed
  • task.completed
  • task.failed
  • task.cancelled
  • task.resumed
  • task.blocker-added
  • task.blocker-removed
  • task.file-added
  • task.file-removed
  • task.mentioned
  • task.facet-updated
  • task.status-set
  • task.subscribed
  • task.unsubscribed

Typische Nutzung:

  • Aufgabe anreichern oder weiterleiten: task.created
  • Folgeaktion bei Abschluss: task.completed
  • Eskalation bei Problemen: task.failed, task.blocker-added

Chats, Inhalte und Kommunikation​

Diese Typen entstehen rund um Assistenten, Chats und eingehende Inhalte:

  • chat.started
  • chat.exited
  • chat.message.sent
  • chat.file-added
  • chat.converted-to-task
  • file.uploaded
  • source.added
  • email.received
  • webhook.received

Typische Nutzung:

  • Reaktion auf neue Nachricht: chat.message.sent
  • Verarbeitung eingehender E-Mails: email.received
  • Reaktion auf Uploads: file.uploaded, chat.file-added
  • Externe Systeme an Automation anschließen: webhook.received

E-Mails direkt in einen Space oder an einen Assistenten senden​

Du kannst E-Mails ohne vorherige Einrichtung direkt an einen Space senden:

<spaceId>@inbound.clye.ai

Dabei ist <spaceId> die ID des Ziel-Space. Wenn der Space einen Assistenten enthält, landet die E-Mail damit im passenden Kontext des Space bzw. des Assistenten.

Wichtig:

  • Dafür ist keine zusätzliche Konfiguration nötig.
  • Nach Eingang der E-Mail entsteht automatisch ein Event vom Typ email.received.
  • Dieses Event kannst du direkt als Auslöser in einer Automation verwenden.

Typische Beispiele:

  • eingehende Anfragen per E-Mail automatisch zusammenfassen
  • Anhänge aus E-Mails weiterverarbeiten
  • aus bestimmten E-Mails Aufgaben oder Benachrichtigungen erzeugen

Spaces, Organisationen und Nutzer​

Diese Typen sind für administrative oder kollaborative Abläufe relevant:

  • space.created
  • space.renamed
  • space.deleted
  • space.member.joined
  • space.member.invited
  • space.member.updated
  • space.member.left
  • space.mcp.server.installed
  • space.mcp.server.uninstalled
  • organization.created
  • organization.updated
  • organization.deleted
  • organization.member.permissionsUpdated
  • user.signedUp
  • user.deleted
  • user.introductionCompleted
  • user.introductionSkipped
  • user.hintAcknowledged
  • user.hintInvalidated
  • user.activeOrganizationSwitched

Typische Nutzung:

  • Onboarding: user.signedUp, space.member.invited
  • Governance und Berechtigungen: organization.member.permissionsUpdated, space.member.updated

Assistenten, Datenbanken, Schlüssel und Webhooks​

Diese Typen betreffen Konfiguration und Plattformobjekte:

  • bot.created
  • bot.updated
  • bot.deleted
  • api.key.created
  • api.key.deleted
  • webhook.created
  • webhook.deleted
  • database.table.updated
  • database.column.updated
  • database.commonColumn.updated
  • database.commonColumn.deleted
  • database.column.commonColumnAssigned
  • rag.patch.requested

Typische Nutzung:

  • Änderungen an Datenmodell oder Tabellen nachverfolgen: database.*
  • Konfigurationsänderungen überwachen: bot.updated, api.key.created

Externe Event-Typen​

Wenn ein externes System CloudEvents an den CLYE AI sendet, wird der ursprüngliche Typ intern mit dem Präfix external. gespeichert.

Beispiele:

  • order.created wird zu external.order.created
  • invoice.sent wird zu external.invoice.sent
  • crm.contact.updated wird zu external.crm.contact.updated

Das ist der wichtigste Mechanismus, um eigene Fachereignisse aus ERP, CRM, Shop, Ticketsystem oder Backend in Automationen zu verwenden.

Wichtig:

  • Der Präfix external. wird automatisch ergänzt.
  • Im Event-Trigger wählst du den internen Typ, also z. B. external.order.created.
  • In event.data findest du die Payload des ursprünglichen CloudEvents.

Eigene fachliche Events als Muster​

Neben systemeigenen und externen Events ist oft ein drittes Muster besonders nützlich: eigene fachliche Events, die du selbst aus einer Automation heraus erzeugst.

Die Idee:

  • Eine erste Automation erkennt etwas technisch, zum Beispiel Dateiänderungen, neue Datensätze oder relevante Unterschiede.
  • Statt sofort alle Folgeschritte direkt in derselben Automation auszuführen, dispatcht sie ein oder mehrere klar benannte Events.
  • Andere Automationen reagieren dann nur noch auf diese fachlichen Events.

Beispiel:

  • Eine Automation erkennt geänderte Dateien.
  • Für jede Änderung erzeugt sie ein Event wie file.changed.
  • Andere Automationen können darauf reagieren, etwa mit Indexierung, Benachrichtigung oder einem späteren LLM-Schritt.

Vorteile dieses Musters:

  • bessere Entkopplung zwischen Erkennung und Verarbeitung
  • einfacher retrybar, weil die fachlichen Schritte sauber getrennt sind
  • ein Eingang kann auf mehrere Ziel-Events gemappt werden
  • mehrere Automationen können unabhängig auf dasselbe Event reagieren

Für produktive Setups ist das oft einfacher und stabiler als eine einzige sehr große Automation.

Welche Typen sehe ich wirklich im Dialog?​

Nicht jeder hier genannte Typ ist in jedem Space sinnvoll oder sofort sichtbar. In der Praxis gilt:

  • Du siehst nur Typen, die im jeweiligen Space bereits vorgekommen sind und für die du Sichtbarkeit hast.
  • Externe Typen erscheinen erst, nachdem mindestens ein passendes externes Event eingegangen ist.
  • Für Conditions und Expressions kannst du dir im Dialog das letzte passende Event als Beispiel anzeigen lassen.

Empfehlung für den Einstieg​

Für die meisten fachlichen Automationen reichen zuerst wenige Typen:

  • task.created
  • task.completed
  • chat.message.sent
  • webhook.received
  • automation.run.failed
  • external.<dein.typ>

Wenn du eigene Geschäftsereignisse abbilden willst, ist fast immer external.<type> der sauberste Einstieg.

Inhalt