Anleitungen · n8n (selbst gehostet)
Auf das Ergebnis eines Requests in n8n reagieren
n8n kann auf zwei Wegen vom Ergebnis eines Requests erfahren: über einen formbase Trigger, der für jeden Request zu einem Formular läuft, oder über einen Wait-Node, der den Workflow pausiert, der den Request erstellt hat. Beide enden in einem Switch auf approve, decline oder changes.
Last checked
Du brauchst eine formbase-Credential in n8n, und dein n8n muss aus dem Internet über HTTPS erreichbar sein; siehe Den formbase-Node in n8n installieren. Um nach einem Urteil zu verzweigen, braucht das Formular eine Entscheidungsfrage. Diese Anleitung nutzt ein Genehmigungsformular mit einer.
| Nutz es wenn | |
|---|---|
| formbase Trigger | Requests zum Formular werden von überall gesendet: dem Dashboard, der API, einem Agenten oder einem anderen Workflow. Ein veröffentlichter Workflow behandelt sie alle. |
| Wait for the Outcome | Der Workflow, der den Request erstellt, soll mit der Antwort fortfahren und alles behalten, was er vorher wusste, wie den Datensatz, an dem er arbeitete. |
Einen Workflow vom Trigger aus starten
1. Das Event wählen
Füg einen formbase Trigger hinzu, wähle die Credential und das Formular, und wähle eines der Request-Events unter Event:
| Event | Feuert wenn | Trägt |
|---|---|---|
| Request Completed | Die empfangende Person sendet das Formular ab. | Den Request, das Ergebnis und jede Antwort. |
| Request Expired | Der Request erreicht sein Ablaufdatum unbeantwortet. | Nur den Request. |
| Request Canceled | Jemand storniert den Request, vom Dashboard, der API oder einem Cancel-request-Node aus, oder formbase storniert ihn, weil das Formular in den Papierkorb verschoben wurde. | Den Request und den Stornierungsgrund. |
2. Mit einem echten Request testen
Ein Test-Request startet nie einen Request-Trigger, sende also einen echten mit Delivery auf None, wie in Einen Request aus einem n8n-Workflow senden, und öffne seinen Link selbst. Klicke dann auf Execute step und sende das Formular innerhalb von zwei Minuten ab.
Das Event trägt neben den Antworten ein data.request-Objekt. Sein outcome ist approve,
decline oder changes, und seine externalId ist die ID, die du gesetzt hast, sodass du den Datensatz
findest, um den es beim Request ging. Jedes Feld steht im Callback-Payload.
Abgelaufene und stornierte Events sind mit Execute step schwer abzufangen. Veröffentliche stattdessen den Workflow und schau in Executions nach.
3. Nach dem Ergebnis verzweigen
Füg einen Switch-Node mit einer Routing-Regel pro Urteil hinzu. Jede Regel vergleicht
{{ $json.data.request.outcome }} mit einem Wert; schalt Rename Output ein, um den Zweig danach zu
benennen:
Verzweige nach data.request.outcome statt nach data.answers.decision: Es fehlt, statt einen anderen Wert zu
tragen, wenn der Request abgelaufen oder storniert wurde. Vergleiche mit Werten, nie mit den Labels in data.display: Ein
Label ändert sich, wenn du die Option umbenennst oder die empfangende Person in einer anderen Sprache antwortet.
Verbinde jeden Zweig mit einem Node, dann Publish den Workflow. Von da an läuft er bei jedem abgeschlossenen Request zum Formular.
Im selben Workflow auf das Ergebnis warten
Hier pausiert der Workflow, der den Request sendet, bis die empfangende Person antwortet, und macht dann weiter. Es braucht drei Änderungen am Workflow aus Einen Request aus einem n8n-Workflow senden.
1. Wait for the Outcome einschalten
Schalt im Node Create request Wait for the Outcome ein. Der Node sendet formbase die Resume-URL dieser Ausführung als Callback des Requests. Lass Callback URL leer; der Node lehnt beide gleichzeitig ab.
Jede Ausführung hat ihre eigene Resume-URL, eine aus einer früheren Ausführung wiederverwendete External ID schlägt also fehl. Nimm
{{ $execution.id }} in sie auf, oder lass sie leer.
2. Einen Wait-Node hinzufügen
Füg direkt danach einen Wait-Node hinzu, mit Resume auf On Webhook Call und der
HTTP-Methode bei POST belassen.
3. Nach dem Event verzweigen
Füg nach dem Wait-Node einen Switch hinzu. Der Wait-Node legt das Event unter body ab, vergleiche also
{{ $json.body.data.request.outcome }}. Um einen abgeschlossenen Request von einem abgelaufenen oder stornierten zu
unterscheiden, vergleiche {{ $json.body.type }} mit request.completed, request.expired oder
request.canceled.
Führ den Workflow aus. Die Ausführung stoppt am Wait-Node, bis die empfangende Person absendet, und macht dann im passenden Zweig weiter:
Auch ein Lauf aus dem Editor wartet auf eine echte Antwort. Test Mode funktioniert hier: Der Callback eines Test-Requests setzt den Workflow trotzdem fort.
Ein Request läuft nach 30 Tagen ab, sofern du kein Expires At setzt, und ein Ablauf setzt die Ausführung mit
request.expiredfort. Setz Expires At, um das Warten früher zu beenden.Der Wait-Node kann den
X-formbase-Signature-Header nicht prüfen; er verlässt sich darauf, dass die Resume-URL schwer zu erraten ist. Reicht das nicht, nutze den formbase Trigger, der jede Zustellung prüft.
Wenn nichts läuft
Es war ein Test-Request. Ein mit aktiviertem Test Mode erstellter Request, oder mit Try it yourself, startet nie einen Request-Trigger. Nur sein Callback feuert.
Der Request war für ein anderes Formular. Der Trigger hört auf das Formular, das du in ihm gewählt hast.
Der Workflow ist nicht veröffentlicht, oder seine Credential erreicht einen anderen Workspace. Siehe die Prüfungen in der Freigabelink-Anleitung.
Create request schlägt fehl mit callbackUrl is not allowed.
Dein n8n gibt eine
http://- oder private Resume-URL heraus. Siehe n8n seine öffentliche Adresse mitteilen.Der Wait-Node setzt nie fort. formbase erreicht die Resume-URL nicht, zum Beispiel weil der Tunnel down ist oder der Proxy
/webhook-waiting/blockiert.