formbasedocs
Zur AppApp

Anleitungen · n8n (selbst gehostet)

Requests in n8n nachschlagen, daran erinnern und stornieren

Fünf formbase-Aktionen arbeiten mit Requests, die schon bestehen. Ein typischer Workflow findet den Request über die ID, unter der ihn dein System kennt, und liest, erinnert oder storniert ihn dann.

Last checked


Du brauchst eine formbase-Credential in n8n und einen mit einer External ID erstellten Request, wie in Einen Request aus einem n8n-Workflow senden. Dieselben Aktionen gibt es im Dashboard; siehe Die Requests-Seite.

Einen Request mit Get many requests finden

Dein System kennt den Lieferanten als SUP-1042, nicht über formbases Request-ID. Füg einen formbase-Node hinzu, wähle Get many requests, und filter nach der External ID, die du beim Erstellen des Requests gesetzt hast:

Der Node Get many requests: Operation Get Many, Return All aus, Limit 50, Scope Workspace, und Filters mit External ID supplier-SUP-1042, Include Test Requests an und Status Pending
  • Scope ist Form, die Vorgabe, die dann nach dem Formular fragt, oder Workspace, jeder Request, den die Credential erreichen kann.

  • Filters engt die Liste nach External ID, Status oder Outcome ein. Include Test Requests ist standardmäßig aus, ein mit aktiviertem Test Mode erstellter Request wird also nicht gefunden. Schalt es an, während du den Workflow mit Test-Requests baust.

  • Der neueste Request kommt zuerst. Limit begrenzt die Anzahl der Items; Return All holt jede Seite.

Jeder Request ist ein Ausgabe-Item, die Nodes danach laufen also einmal pro Request. Findet sich nichts, gibt der Node keine Items aus, und der Workflow stoppt dort; schalt Always Output Data in den Node-Einstellungen ein, um trotzdem fortzufahren. Jeder Node unten nimmt den Request als Request › By ID {{ $json.id }}, oder wähl einen der neuesten Requests unter From list.

Einen Request mit Get request lesen

Get request gibt den Request zurück: seinen Status, sein Ergebnis, die empfangende Person, Zeitstempel, was du vorausgefüllt und gesperrt hast, und seinen Link. Ist er abgeschlossen, trägt er zusätzlich answers und display auf der obersten Ebene, als {{ $json.answers }}. Anders als bei den Events sind seine Zeitstempel Unix-Zeit in Millisekunden.

Mit Remind request recipient eine Erinnerung senden

Remind request recipient schickt der empfangenden Person jetzt eine Erinnerungs-E-Mail. Geplante Erinnerungen gehen weiterhin wie vorgesehen raus. Es funktioniert, wenn:

  • der Request aussteht, sein Ablaufdatum noch nicht erreicht hat, und eine E-Mail-Adresse für die empfangende Person hat,
  • der Workspace auf Pro oder Business ist,
  • die letzte Erinnerung mindestens zehn Minuten her ist, und der Request insgesamt weniger als acht Erinnerungen hatte. Siehe Jetzt nachhaken.

Eine Testanfrage wird nie erinnert. Der Node schlägt fehl mit CONFLICT: This is a test request, so nothing is emailed for it; a reminder has nobody to write to.

Mit Cancel request einen Request zurückziehen

Cancel request zieht einen ausstehenden Request zurück. Der Link funktioniert nicht mehr, und die empfangende Person sieht statt des Formulars einen Hinweis auf den Rückzug. Trag in Reason ein, warum: Das kommt als cancelReason am Request und im Event Request Canceled zurück, sodass ein anderer Workflow es deinem Team sagen kann.

Nur ausstehende Requests können storniert werden

Ein abgeschlossener, abgelaufener oder bereits stornierter Request bleibt, wie er ist, und der Node schlägt mit einem Fehler wie This request is already canceled and cannot be canceled. fehl.

Den Callback mit Replay request callback erneut senden

Hatte ein Request eine Callback-URL, und dein Empfänger hat die Zustellung verpasst, sendet Replay request callback den Callback eines abgeschlossenen, abgelaufenen oder stornierten Requests erneut. Er gibt eine eventId zurück, dieselbe ID wie die erste Zustellung, sodass ein Empfänger, der danach dedupliziert, nur einmal reagiert. Siehe Wiederholungsversuche.

  • Ein Replay geht nur an die Callback-URL des Requests. Ein formbase-Trigger-Abonnement wiederholt sich selbst und wird nicht wiederholt abgespielt.

  • Ein mit Wait for the Outcome erstellter Request hat die Resume-URL einer Ausführung als Callback. Ist diese Ausführung erst beendet, ist die URL weg, ein Replay hilft also nur, solange die Ausführung noch wartet.

Als Nächstes