Guides · n8n (auto-hébergé)
Agir selon le résultat d'une demande dans n8n
n8n peut apprendre le résultat d'une demande de deux façons : un formbase Trigger qui s'exécute pour chaque demande d'un formulaire, ou un nœud Wait qui met en pause le workflow qui a créé la demande. Les deux se terminent par un Switch sur approve, decline ou changes.
Last checked
Il vous faut un credential formbase dans n8n, et votre n8n doit être joignable depuis internet en HTTPS ; voir Installer le nœud formbase dans n8n. Pour bifurquer selon un verdict, le formulaire a besoin d’une question de décision. Ce guide utilise un formulaire d’approbation qui en a une.
| À utiliser quand | |
|---|---|
| formbase Trigger | Les demandes du formulaire sont envoyées de partout : le tableau de bord, l'API, un agent ou un autre workflow. Un seul workflow publié les gère toutes. |
| Wait for the Outcome | Le workflow qui crée la demande doit continuer avec la réponse, en conservant tout ce qu'il savait avant, comme l'enregistrement sur lequel il travaillait. |
Démarrer un workflow depuis le déclencheur
1. Choisissez l’événement
Ajoutez un formbase Trigger, choisissez le credential et le formulaire, et choisissez l’un des événements de demande sous Event :
| Event | Se déclenche quand | Porte |
|---|---|---|
| Request Completed | Le destinataire soumet le formulaire. | La demande, le résultat et chaque réponse. |
| Request Expired | La demande atteint sa date d'expiration sans réponse. | La demande seule. |
| Request Canceled | Quelqu'un annule la demande, depuis le tableau de bord, l'API ou un nœud Cancel request, ou formbase l'annule parce que le formulaire a été déplacé vers la corbeille. | La demande et le motif d'annulation. |
2. Testez-le avec une vraie demande
Une demande de test ne démarre jamais un déclencheur de demande, alors envoyez-en une vraie avec Delivery réglé sur None, comme dans Envoyer une demande depuis un workflow n8n, et ouvrez son lien vous-même. Puis cliquez sur Execute step et soumettez le formulaire dans les deux minutes.
L’événement porte un objet data.request à côté des réponses. Son outcome vaut approve,
decline ou changes, et son externalId est l’ID que vous avez réglé, pour retrouver l’enregistrement
concerné par la demande. Chaque champ est dans le payload du callback.
Les événements d’expiration et d’annulation sont difficiles à capter avec Execute step. Publiez plutôt le workflow et consultez Executions.
3. Bifurquez selon le résultat
Ajoutez un nœud Switch avec une règle de routage par verdict. Chaque règle compare
{{ $json.data.request.outcome }} à une valeur ; activez Rename Output pour nommer la branche d’après
elle :
Bifurquez sur data.request.outcome plutôt que sur data.answers.decision : il est absent, pas juste une autre
valeur, quand la demande a expiré ou a été annulée. Comparez les valeurs, jamais les libellés dans data.display : un libellé
change quand vous renommez l’option ou que le destinataire répond dans une autre langue.
Connectez un nœud à chaque branche, puis Publish le workflow. À partir de là, chaque demande terminée pour le formulaire l’exécute.
Attendre le résultat dans le même workflow
Ici, le workflow qui envoie la demande se met en pause jusqu’à la réponse du destinataire, puis continue. Cela prend trois changements au workflow de Envoyer une demande depuis un workflow n8n.
1. Activez Wait for the Outcome
Dans le nœud Create request, activez Wait for the Outcome. Le nœud envoie à formbase l’URL de reprise de cette exécution comme callback de la demande. Laissez Callback URL vide ; le nœud refuse les deux à la fois.
Chaque exécution a sa propre URL de reprise, donc un External ID réutilisé d’une exécution précédente échoue. Incluez
{{ $execution.id }} dedans, ou laissez-le vide.
2. Ajoutez un nœud Wait
Ajoutez un nœud Wait juste après, avec Resume réglé sur On Webhook Call et la méthode
HTTP laissée sur POST.
3. Bifurquez selon l’événement
Ajoutez un Switch après le nœud Wait. Le nœud Wait place l’événement sous body, donc comparez
{{ $json.body.data.request.outcome }}. Pour distinguer une demande terminée d’une demande expirée ou annulée, comparez
{{ $json.body.type }} à request.completed, request.expired ou request.canceled.
Exécutez le workflow. L’exécution s’arrête au nœud Wait jusqu’à ce que le destinataire soumette, puis reprend sur la branche correspondante :
Une exécution depuis l’éditeur attend aussi une vraie réponse. Test Mode fonctionne ici : le callback d’une demande de test reprend quand même le workflow.
Une demande expire après 30 jours sauf si vous réglez Expires At, et l’expiration reprend l’exécution avec
request.expired. Réglez Expires At pour terminer l’attente plus tôt.Le nœud Wait ne vérifie pas l’en-tête
X-formbase-Signature; il compte sur le fait que l’URL de reprise est difficile à deviner. Si cela ne suffit pas, utilisez le formbase Trigger, qui vérifie chaque événement.
Si rien ne se déclenche
C’était une demande de test. Une demande créée avec Test Mode activé, ou avec Essayez par vous-même, ne démarre jamais un déclencheur de demande. Seul son callback se déclenche.
La demande concernait un autre formulaire. Le déclencheur écoute le formulaire que vous avez choisi dedans.
Le workflow n’est pas publié, ou son credential atteint un autre espace de travail. Voir les vérifications dans le guide du lien public.
Create request échoue avec callbackUrl is not allowed.
Votre n8n distribue une URL de reprise en
http://ou une URL privée. Voir Indiquez à n8n son adresse publique.Le nœud Wait ne reprend jamais. formbase ne peut pas joindre l’URL de reprise, par exemple parce que le tunnel est en panne ou que le proxy bloque
/webhook-waiting/.