Aktionen¶

Die Aktion ist das THEN der Automation: Was soll passieren, wenn Auslöser und optionale Bedingung passen?

Typische Ergebnisse einer Aktion sind zum Beispiel:

Aufgabe erstellen oder aktualisieren
Benachrichtigung senden
Folgeprozess anstoßen
Inhalte vorbereiten, speichern oder weiterreichen

Technisch ist eine Aktion meist ein Tool aus einem integrierten oder angebundenen MCP-Server. Viele eingebaute Server stellen solche Tools direkt als Automation Action bereit.

Für einen vollständigen Überblick siehe:

Katalog der integrierten MCP-Server

Ablauf im Dialog¶

Wähle die Aktion, die fachlich zum gewünschten Ergebnis passt.
Lege fest, welche Angaben dafür nötig sind.
Prüfe, ob das Ergebnis für die Beteiligten verständlich und sinnvoll weiterverwendbar ist.

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

Gute Auswahlkriterien¶

Eine Aktion passt gut, wenn:

das Ergebnis klar erkennbar ist
der nächste Schritt im Prozess wirklich erleichtert wird
Beteiligte nachvollziehen können, was automatisch passiert ist
Fehler oder Mehrfachläufe keine unnötigen Folgeschäden verursachen

Gute erste Aktionen¶

Für den Einstieg eignen sich besonders:

einfache Benachrichtigungen
wiederkehrende Zusammenfassungen
Aufgaben für klar definierte Folgearbeiten
kleine, gut kontrollierbare Weitergaben an andere Bereiche

Typische eingebaute Action-Quellen sind zum Beispiel:

chat/send_message
task_management/task_create
event/event_dispatch
email/email_send
http/http_request
template/template_fill

Beispiel: `event/event_dispatch`¶

event/event_dispatch ist besonders nützlich, wenn du eine Automation nicht direkt alles erledigen lassen willst, sondern zuerst ein fachliches Folge-Event erzeugen möchtest.

Das ist oft sauberer als eine große Einzelautomation, weil dadurch:

Erkennung und Reaktion getrennt werden
Retries einfacher werden
mehrere unterschiedliche Folgeautomationen auf dasselbe Event reagieren können
aus einem Eingang mehrere klar benannte Ziel-Events entstehen können

Beispiel:

Eine erste Automation prüft, welche Dateien sich geändert haben.
Für jede relevante Änderung dispatcht sie ein eigenes Event wie file.changed, file.added oder file.removed.
Andere Automationen reagieren dann gezielt auf genau diese Events, zum Beispiel für Indexierung, Benachrichtigung oder inhaltliche Auswertung.

Das ist oft robuster als eine große Kette aus direktem Code plus sofortigem LLM-Aufruf.

Beispiel: `chat/send_message`¶

Eine besonders nützliche Aktion für HTTP-Trigger ist chat/send_message. Damit kann eine Automation eine Nachricht an einen Assistenten schicken und direkt eine LLM-Antwort auslösen.

Wichtig: Jeder solche Aufruf ist ein echter LLM-Schritt. Er verursacht also typischerweise mehr Kosten und mehr Laufzeit als reine Prüf-, Routing- oder Transformationslogik. Deshalb sollte chat/send_message nicht der erste Reflex sein, wenn dieselbe Frage zunächst günstiger mit Regeln, Conditions oder Code beantwortet werden kann.

Das ist sinnvoll, wenn ein externes System:

einen Fall automatisch zusammenfassen lassen soll
einen Assistenten mit Daten aus einem Formular oder Ticket versorgen soll
eine strukturierte Vorprüfung oder Einschätzung anstoßen soll

Was die Aktion kann¶

chat/send_message unterstützt typischerweise:

chatId, wenn in einen bestehenden Chat geschrieben werden soll
spaceId, wenn ein neuer Chat im Kontext eines Spaces gestartet werden soll
message, also die eigentliche Nutzlast
metadata, wenn zusätzliche Daten mitgegeben werden sollen
intention, um den Schritt im UI verständlicher zu benennen

Wenn du noch keinen Chat hast, ist spaceId oft der sinnvollste Einstieg. Die Aktion startet dann einen neuen Chat und gibt die erzeugte chatId zurück.

Beispiel mit HTTP-Trigger¶

Ein externer Request:

{
  "customerId": "C-4711",
  "ticketId": "T-9001",
  "message": "Kunde meldet wiederkehrendes Login-Problem."
}

Dazu eine Automation:

title: Ticket an Assistenten weitergeben
description: Nimmt HTTP-Requests entgegen und schickt sie an einen Assistenten.

reactions:
  inbound-ticket:
    on:
      http: true
    condition: event.data.method == "POST" && event.data.headers.authorization == "Bearer MEIN_SHARED_SECRET" && event.data.body != null && typeof event.data.body.message == "string"
    run:
      call: chat/send_message
      params:
        spaceId: "11111111-1111-4111-8111-111111111111"
        intention: "Ticket an Assistenten senden"
        message: "{{ 'Neues externes Ticket:\\nKunde: ' + (event.data.body.customerId ?? 'unbekannt') + '\\nTicket: ' + (event.data.body.ticketId ?? 'ohne ID') + '\\nNachricht: ' + (event.data.body.message ?? '') }}"
        metadata:
          source: "http-trigger"
          customerId: "{{ event.data.body.customerId }}"
          ticketId: "{{ event.data.body.ticketId }}"

Wichtig dabei:

Die Condition prüft zuerst Methode, Secret und Pflichtfelder.
In run.params kannst du Werte aus dem HTTP-Request mit {{ ... }} zusammensetzen.
metadata hilft später bei Nachvollziehbarkeit oder Folgeautomationen.

Best Practice:

Erst billig prüfen und filtern, dann erst einen Assistenten aufrufen.
Wenn sich ein Fall vollständig mit Code oder klaren Regeln entscheiden lässt, sollte kein LLM-Schritt nötig sein.
Nutze chat/send_message vor allem dort, wo wirklich Zusammenfassung, Klassifikation, Formulierung oder ein anderer inhaltlicher KI-Schritt gebraucht wird.

Wann bestehender Chat statt neuem Chat sinnvoll ist¶

Nutze chatId, wenn derselbe Vorgang mehrfach ergänzt werden soll, zum Beispiel:

Statusupdates zu demselben Ticket
Rückfragen zu einem bestehenden Fall
mehrstufige Verarbeitung in mehreren Requests

Nutze spaceId, wenn jeder externe Aufruf einen neuen, getrennten Vorgang starten soll.

Hinweis: Welche Aktionen sichtbar sind, hängt von eurer Konfiguration und den Freigaben ab.

Weiter: Im Alltag nutzen – Einführung, Grenzen und Empfehlungen.