Zum Hauptinhalt springen

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:

Ablauf im Dialog​

  1. Wähle die Aktion, die fachlich zum gewünschten Ergebnis passt.
  2. Lege fest, welche Angaben dafür nötig sind.
  3. 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

Gerade bei Aufgaben-Automationen lohnt sich ein genauer Blick auf den gewünschten Kontext:

  • task_management/task_create eignet sich gut, wenn neue Folgeaufgaben direkt mit Anweisungen gestartet werden sollen.
  • Für bestehende Aufgaben kannst du mit task_management/task_subscribe und task_management/task_unsubscribe Abonnenten gezielt hinzufügen oder entfernen, statt die Aufgabe neu anzulegen oder manuell in der Oberfläche nachzupflegen.
  • Für subtaskOf kannst du dabei sowohl eine einzelne Parent-UUID als auch eine Liste von UUIDs übergeben. Gerade in Automationen ist die Einzelangabe als String ein gültiger und typischer Fall.
  • Dasselbe gilt bei blockedBy und blocks: Du kannst jeweils eine einzelne Task-UUID als String oder mehrere UUIDs als Liste übergeben. Das spart in Automationen unnötige Umwandlungen für einfache 1:1-Abhängigkeiten.
  • Wenn du bei einer Unteraufgabe spaceId oder agentId weglässt, übernimmt task_create diese Werte automatisch von subtaskOf – passend zum Verhalten in der UI. Bei mehreren Parents gilt dabei der letzte Eintrag gewinnt. Ein explizites agentId: null bleibt bewusst nicht zugewiesen und wird nicht überschrieben.
  • Für priority erwartet die dokumentierte Tool-Eingabe weiter die Labels low, medium, high, critical oder extreme. In Automationen, die Werte noch direkt ohne vorgeschaltete Schema-Prüfung an task_create senden, werden aber auch Legacy-Zahlen wie 0 bis 4 sowie String-Werte wie "2" weiterhin sauber auf die gespeicherte Priorität abgebildet. Ungültige Werte wie Hoch oder 99 liefern dagegen eine klare Fehlermeldung statt eines technischen Absturzes.
  • Wenn du danach task_get, task_find oder task_update auswertest, kommt priority im Tool-Output ebenfalls als Label zurück, also zum Beispiel high statt 2. Für numerische Sortierung oder Vergleiche kannst du zusätzlich priorityLevel mit dem gespeicherten Wert 0 bis 4 verwenden.
  • Wenn eine neue Aufgabe bewusst mit oder ohne geerbten Kontext laufen soll, prüfe die dafür vorgesehenen Parameter wie parentContext.
  • Für kurze synchrone Folgeabläufe kann danach ein gezieltes Warten auf das Ergebnis sinnvoll sein; für längere Abläufe bleiben sichtbare Task-Beziehungen meist robuster.

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:

  • threadId, wenn in einen bestehenden Chat-Thread geschrieben werden soll
  • chatId weiterhin als Alias, wenn bestehende Integrationen diesen Namen schon verwenden
  • 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 Thread-ID zurück. In bestehenden Integrationen kannst du dafür je nach Kontext weiter mit chatId arbeiten; empfohlen ist für bestehende Threads jetzt threadId.

Wichtig: Für einen neuen Chat muss spaceId immer die UUID des Ziel-Spaces sein – zum Beispiel die UUID aus einem /spaces/{spaceId}-Link. Verwende dafür nicht die UUID eines Bots oder Assistenten selbst.

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.
  • Beim Schreiben solcher Ausdrücke unterstützt dich der Inline-Editor mit Syntaxhervorhebung und Autovervollständigung für Event-Daten und Helper.
  • 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 dafür bevorzugt threadId – oder weiter chatId als Alias, wenn bestehende Automationen schon darauf aufbauen –, 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.

Inhalt