Zum Hauptinhalt springen

Event-Typen für Automationen

Im Zusammenspiel mit Facets bleiben Event-Typen fachlich anschlussfähig: Dieselben Entitäten, IDs oder Facet-Pfade können von Wissen, Tools und Prozessen gemeinsam genutzt werden. Mehr dazu im Architekturvergleich. 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.

Event-Typen im Trigger und im Event Schema​

Es gibt jetzt zwei sinnvolle Sichten auf Event-Typen:

  • Typen: Hier pflegst oder prüfst du bekannte Event-Typen und ihre Definitionen im Space.
  • Event Schema: Hier siehst du, wie diese Typen im Space tatsächlich verwendet werden – also welche Events produziert werden, welche lokale Reactions konsumieren und welche anderen Spaces auf deine Events hören.

Die Schema-Ansicht ist besonders hilfreich, wenn du Cross-Space-Automationen nachvollziehen, Payloads prüfen oder die letzten Vorkommen eines Event-Typs ansehen möchtest.

So liest du die Liste​

  • Der Event-Trigger filtert auf event.type.
  • In Bedingungen und Action-Parametern arbeitest du typischerweise mit event.data.
  • Viele Typen tauchen im Auswahlfeld erst dann auf, wenn es in diesem Space schon mindestens ein passendes Event gab.
  • Einige systemseitig eingebaute Chat-Events wie chat.exited können im Auswahlfeld bereits sichtbar sein, auch wenn in deinem Space noch kein solches Event ausgelöst wurde.
  • Standardmäßig wertet eine Event-Automation nur Ereignisse aus dem eigenen Space aus. Wenn du im Trigger Quell-Spaces auswählst, kann derselbe Event-Typ gezielt auch aus anderen Spaces verarbeitet werden.
  • In der Schema-Ansicht erkennst du zusätzlich, ob ein Typ nur lokal genutzt wird oder ob Cross-Space-Bezüge über sourceSpaces oder konsumierende Reactions aus anderen Spaces bestehen.

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

Event-Herkunft über mehrere Spaces​

Wenn eine Automation auf Events reagiert, gibt es jetzt zwei typische Modelle:

  • Standardfall: Die Automation verarbeitet nur Events aus ihrem eigenen Space.
  • Mit Quell-Spaces: Im Event-Trigger kannst du zusätzliche Producer-Spaces auswählen. Dann läuft die Automation weiterhin im eigenen Space, reagiert aber auch auf Events aus diesen ausgewählten Quellen.

Das ist hilfreich für zentrale Monitoring-, Routing- oder Benachrichtigungs-Automationen. In der Oberfläche können dafür je nach Ansicht zusätzliche Herkunftsfelder wie Quelle, sourceSpaceId oder sourceSpaceName sichtbar sein.

Wichtig: Das bestehende Push-Modell über event_dispatch mit spaceIds bleibt davon unberührt. Quell-Spaces erweitern nur das Pull-Modell für Event-Trigger.

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.mentioned ist besonders für Aufgaben-Kommentare mit gezielten Assistenten- oder Space-Erwähnungen relevant. Ausgelöst wird der Event, wenn der Kommentar eine echte Mention als Link wie [Name](/spaces/<uuid>) enthält. Ein bloßes @Name ohne diesen verknüpften Space-Link reicht dafür nicht.

  • 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
  • Reaktion auf neue Abonnements direkt beim Erstellen oder später: task.subscribed

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, task.file-added
  • Externe Systeme an Automation anschließen: webhook.received (eingehende Webhook-Aufrufe, nicht zu verwechseln mit ausgehenden Webhooks)

Hinweis für chat.started:

  • Wenn ein Chat in einem Space ohne Bot/Assistenten startet, kann event.data.botId ausdrücklich null sein.
  • Prüfe event.data.botId in Conditions oder Code deshalb defensiv und behandle den Wert nicht als immer gesetzt.
  • Für den fachlichen Kontext sind je nach Anwendungsfall oft event.spaceIds, event.objectId oder weitere Felder in event.data robuster als eine harte Prüfung nur auf botId.

Beispiel für eine defensive Condition:

event.type == "chat.started" && event.data != null && event.data.botId != null

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.
  • Wenn zum Event eine gespeicherte .eml-Datei gehört, kann in der Oberfläche ein direkter Link E-Mail öffnen zur Vorschau erscheinen. Dort werden auch eingebettete Inline-Bilder aus der E-Mail angezeigt, einschließlich cid:-Bildern.
  • 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

Vorschau- und Download-Links bei Datei-Events​

Bei Datei-Events wie file.uploaded, chat.file-added und task.file-added kann die Oberfläche direkte Links zur hochgeladenen Datei anzeigen, zum Beispiel für Vorschau oder Download.

Das ist besonders nützlich, wenn du ein Event nicht nur technisch auswerten, sondern die betroffene Datei auch direkt prüfen oder öffnen möchtest.

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:

  • Viele Typen siehst du erst, wenn sie im jeweiligen Space bereits vorgekommen sind und du dafür Sichtbarkeit hast.
  • Einige eingebaute Chat-Events sind davon ausgenommen und können schon vorher im Auswahlfeld erscheinen.
  • 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. Dabei folgen Beispiel-Events denselben Trigger-Filtern wie der Dialog: Event-Typ sowie optional gesetzte Objekt-ID und Source-Spaces.
  • Gibt es dafür noch kein passendes Event, bleibt ein Platzhalter sichtbar. Eine eingetragene Objekt-ID bleibt im Beispiel trotzdem erhalten.

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