Partez d’une exécution précise. Relevez son statut, le premier nœud en échec, son message et les données qu’il a reçues. Un problème de livraison du déclencheur et un problème de traitement n’ont pas le même point de départ.
Aucune exécution n’apparaît
Vérifiez que le workflow est publié et que vous avez republié les changements du déclencheur.
Pour un webhook, reprenez l’URL affichée par le nœud, la méthode HTTP et l’authentification configurées. Vérifiez la réponse reçue par l’appelant.
Pour un événement fournisseur, vérifiez que le bon événement est activé et que le service peut joindre l’instance. Consultez son historique de livraison s’il en propose un.
Pour une planification, vérifiez le mode, les jours et le fuseau horaire dans la fiche du nœud.
Un payload simulé dans l’éditeur ne teste pas ces conditions de livraison. Si le workflow fonctionne avec ce payload, concentrez la recherche sur le déclencheur et la connexion externe.
Le webhook répond mais une étape a échoué
Le mode de réponse immédiate renvoie une réponse avant la fin du traitement. Retrouvez l’exécution dans l’historique et vérifiez son statut final. Si l’appelant a besoin du résultat métier, configurez un mode de réponse qui attend ce résultat ; consultez Webhook et Réponse webhook.
Une expression est vide ou null
Vérifiez successivement :
La forme de l’entrée : input.email pour un payload manuel simple, souvent input.body.email pour un webhook JSON.
Le nom technique : utilisez celui proposé par le mapping, par exemple nodes.http1, pas un nom de service deviné.
La sortie réelle : avec Corps uniquement, nodes.http1.body.id peut devenir nodes.http1.id.
La branche exécutée : un nœud dans une branche non parcourue ne fournit pas de sortie.
Le périmètre du test : un test isolé ne prouve pas que les étapes amont ont été exécutées avec les mêmes données. Relancez la chaîne concernée.
Consultez les diagnostics d’expression dans les logs et le guide des données. Un défaut facultatif avec ?? peut être utile ; il ne remplace pas la validation d’un champ obligatoire.
Le nœud reçoit du texte au lieu d’un objet ou d’un nombre
Dans Modifier les champs, 120 est du texte et {{ 120 }} est un nombre. Une expression seule peut conserver un objet ou une liste ; une valeur mêlant texte et expression devient une chaîne.
Les variables créées par ce nœud sont textuelles. Pour conserver le type, utilisez sa sortie nodes.set1.<champ>. Si la source contient réellement une chaîne JSON, utilisez Parse JSON et sa propriété parsed.
Une condition prend la mauvaise branche
Ouvrez la sortie du IF : conditions montre la valeur lue, l’opérateur, la valeur comparée et le résultat de chaque condition. result montre leur combinaison finale.
Vérifiez le chemin du champ, les majuscules et espaces pour une égalité de texte, et le choix AND ou OR. Les comparaisons gt, gte, lt et lte sont numériques ; une valeur vide n’est pas une preuve de validité numérique. Vérifiez aussi que les connexions partent de la bonne sortie vrai ou faux.
La boucle ne traite qu’un lot ou utilise le mauvais élément
Vérifiez que la source pointe sur la liste voulue et que l’action répétée part de la sortie Boucle, pas de Terminé. Avec batchSize: 1, le nœud expose l’élément dans item. Avec des lots plus grands, item peut être une liste.
input reste l’entrée initiale : utilisez la sortie de la boucle pour lire l’élément courant. Testez avec deux éléments distincts afin de repérer une action qui réutilise toujours le premier.
L’identifiant n’est pas proposé ou l’accès est refusé
Vérifiez le type exact attendu par le nœud et le partage de l’identifiant avec le propriétaire du workflow. Des accès SMTP et IMAP, ou PostgreSQL et pgvector, ne sont pas interchangeables.
Si l’identifiant est sélectionné mais que l’opération échoue, relevez la réponse du service. Un problème d’authentification et un droit insuffisant nécessitent des corrections différentes. Le guide des identifiants donne l’ordre de vérification.
Une requête HTTP renvoie une erreur
401 ou 403 : vérifiez le mode d’authentification, l’accès sélectionné et les permissions sur la ressource.
404 : vérifiez l’URL construite, l’identifiant de ressource et l’environnement appelé.
429 : vérifiez les limites du fournisseur et réduisez la cadence ; une relance immédiate en boucle peut aggraver le problème.
5xx ou délai dépassé : vérifiez la disponibilité du service et les effets déjà produits avant de réessayer une écriture.
Le nœud HTTP échoue par défaut sur une réponse hors 2xx. Pour traiter volontairement un statut dans un IF, désactivez Échouer sur les erreurs HTTP, gardez Inclure le statut et désactivez Corps uniquement. Prévoyez une branche d’échec explicite : le succès technique du nœud ne signifie alors plus le succès de la requête.
Une action a été exécutée deux fois
Comparez les identifiants d’exécution et d’événement. Déterminez si le fournisseur a livré deux événements, si vous avez relancé manuellement, ou si une politique de réessai a rejoué une étape déjà effectuée.
Avant une nouvelle relance, vérifiez l’état chez le destinataire. Utilisez une clé d’idempotence quand l’API la prévoit, ou une vérification du traitement déjà effectué à partir d’un identifiant métier stable. Le guide des exécutions explique les différents périmètres de réessai.
L’exécution reste en pause
Une pause peut correspondre à une attente prévue ou à une approbation d’outil d’agent. Ouvrez l’exécution pour voir la demande. Pour une approbation, vérifiez l’action et ses arguments, puis utilisez Approuver et reprendre ou Refuser et reprendre avec un compte autorisé.
Ne relancez pas tout le workflow pour répondre à une approbation : vous pourriez répéter les étapes précédentes. Consultez Approbation des outils d’agent.
L’agent échoue ou répond sans les données attendues
Vérifiez le modèle et l’identifiant sélectionnés, les ports des composants et les noms des outils. Un outil mentionné dans le prompt doit aussi être relié et configuré. Consultez la trace pour savoir s’il a réellement été appelé.
En cas de limite de tours ou de tokens, réduisez d’abord la tâche et le contexte, puis ajustez la limite concernée. maxTokens borne la sortie d’un appel ; maxTotalTokens borne l’usage cumulé de cet agent. Un budget total nécessite que le fournisseur retourne les informations d’usage.
Pour une recherche documentaire, inspectez les passages retrouvés et vérifiez que question et documents utilisent le même modèle d’embeddings et la même dimension. Le guide des workflows distingue indexation et question.
Préparer une demande de support
Rassemblez le nom et la version de l’instance, l’heure de l’incident avec son fuseau, l’identifiant de l’exécution, le type du nœud, le message exact et les étapes de reproduction. Précisez le résultat attendu, le résultat obtenu et si l’incident concerne un test ou un événement réel.
Joignez un exemple minimal anonymisé. Retirez clés API, tokens, cookies, en-têtes d’authentification et données personnelles des payloads, captures et logs.
Partez d’une exécution précise. Relevez son statut, le premier nœud en échec, son message et les données qu’il a reçues. Un problème de livraison du déclencheur et un problème de traitement n’ont pas le même point de départ.
Aucune exécution n’apparaît
Un payload simulé dans l’éditeur ne teste pas ces conditions de livraison. Si le workflow fonctionne avec ce payload, concentrez la recherche sur le déclencheur et la connexion externe.
Le webhook répond mais une étape a échoué
Le mode de réponse immédiate renvoie une réponse avant la fin du traitement. Retrouvez l’exécution dans l’historique et vérifiez son statut final. Si l’appelant a besoin du résultat métier, configurez un mode de réponse qui attend ce résultat ; consultez Webhook et Réponse webhook.
Une expression est vide ou null
Vérifiez successivement :
input.emailpour un payload manuel simple, souventinput.body.emailpour un webhook JSON.nodes.http1, pas un nom de service deviné.nodes.http1.body.idpeut devenirnodes.http1.id.Consultez les diagnostics d’expression dans les logs et le guide des données. Un défaut facultatif avec
??peut être utile ; il ne remplace pas la validation d’un champ obligatoire.Le nœud reçoit du texte au lieu d’un objet ou d’un nombre
Dans Modifier les champs,
120est du texte et{{ 120 }}est un nombre. Une expression seule peut conserver un objet ou une liste ; une valeur mêlant texte et expression devient une chaîne.Les variables créées par ce nœud sont textuelles. Pour conserver le type, utilisez sa sortie
nodes.set1.<champ>. Si la source contient réellement une chaîne JSON, utilisez Parse JSON et sa propriétéparsed.Une condition prend la mauvaise branche
Ouvrez la sortie du IF :
conditionsmontre la valeur lue, l’opérateur, la valeur comparée et le résultat de chaque condition.resultmontre leur combinaison finale.Vérifiez le chemin du champ, les majuscules et espaces pour une égalité de texte, et le choix AND ou OR. Les comparaisons
gt,gte,ltetltesont numériques ; une valeur vide n’est pas une preuve de validité numérique. Vérifiez aussi que les connexions partent de la bonne sortie vrai ou faux.La boucle ne traite qu’un lot ou utilise le mauvais élément
Vérifiez que la source pointe sur la liste voulue et que l’action répétée part de la sortie Boucle, pas de Terminé. Avec
batchSize: 1, le nœud expose l’élément dansitem. Avec des lots plus grands,itempeut être une liste.inputreste l’entrée initiale : utilisez la sortie de la boucle pour lire l’élément courant. Testez avec deux éléments distincts afin de repérer une action qui réutilise toujours le premier.L’identifiant n’est pas proposé ou l’accès est refusé
Vérifiez le type exact attendu par le nœud et le partage de l’identifiant avec le propriétaire du workflow. Des accès SMTP et IMAP, ou PostgreSQL et pgvector, ne sont pas interchangeables.
Si l’identifiant est sélectionné mais que l’opération échoue, relevez la réponse du service. Un problème d’authentification et un droit insuffisant nécessitent des corrections différentes. Le guide des identifiants donne l’ordre de vérification.
Une requête HTTP renvoie une erreur
Le nœud HTTP échoue par défaut sur une réponse hors 2xx. Pour traiter volontairement un statut dans un IF, désactivez Échouer sur les erreurs HTTP, gardez Inclure le statut et désactivez Corps uniquement. Prévoyez une branche d’échec explicite : le succès technique du nœud ne signifie alors plus le succès de la requête.
Une action a été exécutée deux fois
Comparez les identifiants d’exécution et d’événement. Déterminez si le fournisseur a livré deux événements, si vous avez relancé manuellement, ou si une politique de réessai a rejoué une étape déjà effectuée.
Avant une nouvelle relance, vérifiez l’état chez le destinataire. Utilisez une clé d’idempotence quand l’API la prévoit, ou une vérification du traitement déjà effectué à partir d’un identifiant métier stable. Le guide des exécutions explique les différents périmètres de réessai.
L’exécution reste en pause
Une pause peut correspondre à une attente prévue ou à une approbation d’outil d’agent. Ouvrez l’exécution pour voir la demande. Pour une approbation, vérifiez l’action et ses arguments, puis utilisez Approuver et reprendre ou Refuser et reprendre avec un compte autorisé.
Ne relancez pas tout le workflow pour répondre à une approbation : vous pourriez répéter les étapes précédentes. Consultez Approbation des outils d’agent.
L’agent échoue ou répond sans les données attendues
Vérifiez le modèle et l’identifiant sélectionnés, les ports des composants et les noms des outils. Un outil mentionné dans le prompt doit aussi être relié et configuré. Consultez la trace pour savoir s’il a réellement été appelé.
En cas de limite de tours ou de tokens, réduisez d’abord la tâche et le contexte, puis ajustez la limite concernée.
maxTokensborne la sortie d’un appel ;maxTotalTokensborne l’usage cumulé de cet agent. Un budget total nécessite que le fournisseur retourne les informations d’usage.Pour une recherche documentaire, inspectez les passages retrouvés et vérifiez que question et documents utilisent le même modèle d’embeddings et la même dimension. Le guide des workflows distingue indexation et question.
Préparer une demande de support
Rassemblez le nom et la version de l’instance, l’heure de l’incident avec son fuseau, l’identifiant de l’exécution, le type du nœud, le message exact et les étapes de reproduction. Précisez le résultat attendu, le résultat obtenu et si l’incident concerne un test ou un événement réel.
Joignez un exemple minimal anonymisé. Retirez clés API, tokens, cookies, en-têtes d’authentification et données personnelles des payloads, captures et logs.