Trigger-Knoten

Jeder Workflow beginnt mit genau einem Trigger. Er legt fest, wann der Workflow läuft und welche Daten er weitergibt. Bis auf den manuellen Trigger lösen Trigger erst aus, wenn Sie eine Version bereitgestellt haben und der Workflow Aktiv ist.

Manueller Trigger

Läuft, wenn Sie im Builder auf Test ausführen klicken. Nutzen Sie ihn für Workflows, die Sie bei Bedarf starten, und während des Aufbaus.

Keine Konfiguration nötig.

Webhook-Trigger

Läuft, wenn eine HTTP-Anfrage an der Webhook-URL des Workflows eingeht:

https://<Ihre DeutschlandGPT-Adresse>/workflows/api/v1/webhook/<Workflow-ID>

Pro Workflow gibt es genau eine URL. Die Webhook-URL steht im Panel des Triggers; kopieren Sie sie von dort. Sie nimmt GET, POST, PUT, PATCH und DELETE an. Ein JSON-Body wird zur Ausgabe payload. Ohne JSON-Body ist payload ein leeres Objekt.

Die URL nimmt erst Anfragen an, wenn eine Version bereitgestellt ist. Jede aufrufende Adresse kann einen Workflow bis zu 60-mal pro Minute und 5.000-mal pro Tag auslösen; darüber antwortet der Webhook mit Status 429.

Zum Testen ohne externes System klicken Sie im Panel des Triggers auf Webhook-Testdaten erstellen und geben ein Beispiel-JSON ein.

Antwort konfigurieren

Standardmäßig antwortet der Webhook mit Status 200 und einem JSON-Objekt aus success, executionId und message. Unter Erweiterte Einstellungen legen Sie eine eigene Antwort fest:

Im Body steht zur Verfügung, was beim Eingang der Anfrage schon bekannt ist:

• {{<Trigger>.outputs.payload.feld}}: ein Feld aus dem Body der Anfrage, so geschrieben, wie das Panel Variablen es einfügt
• {{<Trigger>.outputs.triggeredAt}}: der Eingangszeitpunkt
• {{executionId}} und {{workflowId}}

Die Antwort geht hinaus, sobald die Ausführung eingeplant ist, nicht erst an ihrem Ende. Die Ausgabe eines späteren Knotens lässt sich deshalb nicht zurückgeben. Ein solcher Ausdruck bleibt wörtlich in der Antwort stehen, damit der Fehler auffällt. Abgelehnte Anfragen behalten ihren eigenen Status und ihren JSON-Fehlertext: unbekannter Workflow, falsches Secret, Workflow nicht bereitgestellt oder Rate-Limit überschritten.

Formular-Trigger

Läuft, wenn jemand das Formular des Workflows absendet. Das Formular liegt unter /workflows/<Workflow-ID>/form; die Formular-URL steht im Panel des Triggers. Was die Absender sehen, beschreibt die Seite Formulare.

Die Eingaben heißen im Knoten auch in der deutschen Oberfläche wie folgt:

Access Control kennt drei Werte:

• Private (Only owner): nur Sie selbst, angemeldet
• Workspace (Members only): angemeldete Mitglieder Ihres Arbeitsbereichs
• Public (Anyone): alle, die den Link haben, ohne Anmeldung

Jedes Feld hat einen Schlüssel, eine Bezeichnung, einen Typ und die Angabe, ob es Pflicht ist, dazu optional eine Beschreibung und einen Platzhalter. Die Feldtypen sind Text, Mehrzeiliger Text, Dropdown, Checkbox, Zahl, Datum und Datei-Upload. Zahlenfelder nehmen ein Minimum und Maximum, Dropdowns eine Liste von Optionen, Dateifelder die erlaubten Dateitypen, eine Höchstgröße (standardmäßig 10 MB) und ob mehrere Dateien erlaubt sind (standardmäßig bis zu 5).

Ein Feld erreichen Sie mit {{formTrigger.outputs.formData.<Schlüssel>}}, vorne mit dem Variablennamen Ihres Triggers.

Geplanter Trigger

Führt den Workflow nach Zeitplan aus. Wählen Sie im Feld Schedule des Triggers einen der Vordefinierten Zeitpläne oder tippen Sie eine Beschreibung wie „werktags um 8“ ein und lassen Sie die KI daraus einen Ausdruck machen. Das Feld zeigt die nächsten fünf Ausführungszeiten.

Zeitpläne gelten in deutscher Zeit (Europe/Berlin), einschließlich der Umstellung auf Sommer- und Winterzeit.

Der Ausdruck folgt dem sechsteiligen Cron-Format von AWS EventBridge:

Minute  Stunde  Tag-im-Monat  Monat  Wochentag  Jahr

• Entweder Tag-im-Monat oder Wochentag muss ? sein, niemals beide.
• Der Wochentag zählt von 1 = Sonntag bis 7 = Samstag. Montag bis Freitag ist also 2-6.

Integrations-Trigger

Starten einen Workflow, wenn in einem verbundenen Dienst etwas passiert, etwa bei einer neuen E-Mail in Outlook oder Gmail, einer neuen Nachricht in einem Slack-Kanal oder einem neuen Jira-Issue. Öffnen Sie in der Knotenauswahl Trigger → Integrations-Trigger, wählen Sie Dienst und Ereignis und legen Sie die Verbindung fest.

Welche Ereignisse es gibt, steht auf der Seite der jeweiligen Integration. Test-Event abrufen im Panel des Triggers holt ein echtes Ereignis aus dem Dienst und heftet es als Testdaten an.

Wird die Verbindung hinter einem bereitgestellten Trigger gelöscht oder verliert sie den Zugriff, wird der Workflow deaktiviert, und der Builder zeigt am Trigger einen Hinweis.

Subworkflow-Trigger

Macht den Workflow aus anderen Workflows aufrufbar, über den Knoten Subworkflow.

Unter Parameter legen Sie fest, was der Aufrufer übergibt. Jeder Parameter hat einen Schlüssel, eine Bezeichnung, einen Typ (string, number, boolean, object oder array) und die Angabe, ob er Pflicht ist. Die Parameter werden zu den Ausgaben des Triggers für die folgenden Knoten. Unter Testdaten tragen Sie Beispielwerte ein, um den Subworkflow für sich allein zu testen.

Ein Subworkflow läuft beim Aufruf nur, wenn er bereitgestellt, aktiv und im selben Arbeitsbereich wie der Aufrufer ist.