Guides · n8n (auto-hébergé)
Trouver, relancer et annuler des demandes dans n8n
Cinq actions formbase agissent sur des demandes qui existent déjà. Un workflow typique trouve la demande par l'ID sous lequel votre système la connaît, puis la lit, la relance ou l'annule.
Last checked
Il vous faut un credential formbase dans n8n et une demande créée avec un External ID, comme dans Envoyer une demande depuis un workflow n8n. Les mêmes actions existent dans le tableau de bord ; voir La page Demandes.
Trouver une demande avec Get many requests
Votre système connaît le fournisseur sous SUP-1042, pas sous l’ID de demande formbase. Ajoutez un nœud formbase, choisissez
Get many requests, et filtrez par l’External ID que vous avez réglé quand vous avez créé la demande :
Scope vaut Form, la valeur par défaut, qui demande alors le formulaire, ou Workspace, chaque demande que le credential peut atteindre.
Filters affine la liste par External ID, Status ou Outcome. Include Test Requests est désactivé par défaut, donc une demande créée avec Test Mode activé n’est pas trouvée. Activez-le pendant que vous construisez le workflow avec des demandes de test.
La demande la plus récente vient en premier. Limit plafonne le nombre d’éléments ; Return All récupère chaque page.
Chaque demande est un élément de sortie, donc les nœuds suivants s’exécutent une fois par demande. Quand rien ne correspond, le nœud ne
produit aucun élément et le workflow s’arrête là ; activez Always Output Data dans les réglages du nœud pour continuer.
Chaque nœud ci-dessous prend la demande comme Request › By ID {{ $json.id }}, ou
choisissez l’une des demandes les plus récentes sous From list.
Lire une demande avec Get request
Get request renvoie la demande : son statut, son résultat, son destinataire, ses horodatages, ce que vous avez prérempli
et verrouillé, et son lien. Une fois terminée, elle porte aussi answers et display au niveau racine, comme
{{ $json.answers }}. Contrairement aux événements, ses horodatages sont en temps Unix, en millisecondes.
Envoyer un rappel avec Remind request recipient
Remind request recipient envoie maintenant un e-mail de rappel au destinataire. Les rappels planifiés partent quand même comme prévu. Cela fonctionne quand :
- la demande est en attente, n’a pas dépassé sa date d’expiration, et a un e-mail de destinataire,
- l’espace de travail est sur Pro ou Business,
le dernier rappel a été envoyé il y a au moins dix minutes, et la demande a eu moins de huit rappels au total. Voir Relancer quelqu’un maintenant.
Une demande de test n’est jamais relancée. Le nœud échoue avec CONFLICT: This is a test request, so nothing is emailed for it; a reminder has nobody to write to.
Retirer une demande avec Cancel request
Cancel request retire une demande en attente. Le lien cesse de fonctionner, et le destinataire voit un avis de retrait au
lieu du formulaire. Remplissez Reason pour enregistrer pourquoi : cela revient comme cancelReason sur la
demande et dans l’événement Request Canceled, pour qu’un autre workflow puisse en informer
votre équipe.
Seules les demandes en attente peuvent être annulées
Une demande terminée, expirée ou déjà annulée reste telle quelle, et le nœud échoue avec une erreur telle que This request is already canceled and cannot be canceled.
Renvoyer le callback avec Replay request callback
Si une demande avait une URL de callback et que votre récepteur a manqué la livraison, Replay request callback renvoie le
callback d’une demande terminée, expirée ou annulée. Il renvoie un eventId, le même ID que la première livraison, pour qu’un
récepteur qui déduplique dessus n’agisse qu’une fois. Voir les nouvelles tentatives.
Un replay va uniquement vers l’URL de callback de la demande. Un abonnement formbase Trigger fait ses propres nouvelles tentatives et n’est pas rejoué.
Une demande créée avec Wait for the Outcome a l’URL de reprise d’une exécution comme callback. Une fois cette exécution terminée, l’URL a disparu, donc un replay n’aide que tant que l’exécution attend encore.