Une exécution correspond à un lancement du workflow. Pour vérifier une automatisation, cherchez à la fois un statut final correct et le résultat attendu : le bon destinataire, les champs créés et l’absence d’effet indésirable.
Lire le statut
pending : l’exécution attend son traitement.
running : le traitement est en cours.
paused : le traitement attend une reprise, par exemple après une attente ou une demande d’approbation.
success : l’exécution s’est terminée sans échec technique remonté au moteur.
failed : une erreur a fait échouer l’exécution.
cancelled : l’exécution a été annulée.
success ne garantit pas à lui seul un résultat métier. Un IF peut avoir pris une branche inattendue, et un nœud HTTP peut être configuré pour accepter les statuts d’erreur. Vérifiez les sorties et la cible réelle.
Tester une étape
Un test isolé sert à examiner une configuration. Une exécution de chaîne vérifie aussi la préparation des données amont. Une exécution complète permet de vérifier les branches et le comportement d’ensemble.
Après un changement de mapping, relancez les étapes qui produisent les données, puis le consommateur. Vérifiez :
L’entrée reçue correspond au cas testé.
La sortie contient le champ et le type attendus.
Les expressions du nœud suivant lisent cette sortie réelle.
La destination de test contient le résultat attendu si une action externe a eu lieu.
Un test peut envoyer un message ou modifier des données si vous lancez une action réelle. Utilisez des accès et des destinations de test pour ces vérifications.
Lire une erreur
Partez du premier nœud en échec dans l’ordre d’exécution. Relevez son message exact, puis comparez sa configuration et les données reçues. Les étapes suivantes non exécutées sont souvent une conséquence de cet échec.
Pour une intégration, vérifiez ensuite l’identifiant, les droits sur la ressource et la réponse du service. Pour une expression vide, vérifiez la structure et les noms techniques avant de changer le service appelé. Le dépannage par symptôme aide à choisir le bon contrôle.
Réessais et workflow de secours
Les paramètres du workflow permettent de stopper, de réessayer le workflow complet ou le nœud échoué, ou de lancer un autre workflow publié du même propriétaire. Les réessais du nœud sont épuisés avant la politique globale. Les tests de nœud et les exécutions partielles ignorent cette politique.
Choisissez le périmètre en fonction des effets déjà réalisés :
Nœud échoué : évite de rejouer volontairement toute la chaîne, mais le service peut avoir effectué l’action avant qu’une réponse soit perdue.
Workflow complet : rejoue aussi les étapes précédentes, y compris les écritures déjà réussies.
Workflow de secours : permet de notifier ou traiter l’incident sans transformer l’exécution d’origine en succès.
Le workflow de secours reçoit l’exécution en échec dans input.payload.execution et les informations de l’appelant dans input.source. Il démarre sans attendre sa fin ; l’exécution d’origine reste en échec.
Approbation des outils d’agent
Un outil avec requireApproval: true suspend le workflow. Dans l’historique, une personne autorisée examine l’action et ses arguments, puis choisit Approuver et reprendre ou Refuser et reprendre. Un refus est transmis au modèle sans exécuter l’action refusée. La reprise restaure les messages et les outils déjà terminés, y compris après redémarrage.
Chaque appel protégé demande sa propre décision. Cette pause nécessite un workflow complet, hors boucle, appel inline ou agent imbriqué. Pour répondre à une approbation, reprenez l’exécution concernée au lieu de lancer une nouvelle exécution complète.
Déclencheurs externes
Après publication, provoquez un événement réel et retrouvez l’exécution correspondante grâce à l’heure, au type de déclencheur et à un identifiant de test présent dans les données. Vérifiez sa fin et le résultat dans le service cible.
Un test avec payload simulé valide uniquement le traitement de cet exemple. Il ne vérifie pas le réseau, l’authentification entrante, les abonnements aux événements ou l’horaire planifié. Un webhook en réponse immédiate peut aussi répondre avant la fin du workflow.
Conservation de l’historique
Les offres prévoient des droits de conservation et de détail des exécutions. Consultez Tarifs et licences et votre offre active pour connaître les valeurs applicables. Pour une demande de support, relevez les informations nécessaires pendant qu’elles sont disponibles, en retirant les secrets et données personnelles.
Une exécution correspond à un lancement du workflow. Pour vérifier une automatisation, cherchez à la fois un statut final correct et le résultat attendu : le bon destinataire, les champs créés et l’absence d’effet indésirable.
Lire le statut
pending: l’exécution attend son traitement.running: le traitement est en cours.paused: le traitement attend une reprise, par exemple après une attente ou une demande d’approbation.success: l’exécution s’est terminée sans échec technique remonté au moteur.failed: une erreur a fait échouer l’exécution.cancelled: l’exécution a été annulée.successne garantit pas à lui seul un résultat métier. Un IF peut avoir pris une branche inattendue, et un nœud HTTP peut être configuré pour accepter les statuts d’erreur. Vérifiez les sorties et la cible réelle.Tester une étape
Un test isolé sert à examiner une configuration. Une exécution de chaîne vérifie aussi la préparation des données amont. Une exécution complète permet de vérifier les branches et le comportement d’ensemble.
Après un changement de mapping, relancez les étapes qui produisent les données, puis le consommateur. Vérifiez :
Un test peut envoyer un message ou modifier des données si vous lancez une action réelle. Utilisez des accès et des destinations de test pour ces vérifications.
Lire une erreur
Partez du premier nœud en échec dans l’ordre d’exécution. Relevez son message exact, puis comparez sa configuration et les données reçues. Les étapes suivantes non exécutées sont souvent une conséquence de cet échec.
Pour une intégration, vérifiez ensuite l’identifiant, les droits sur la ressource et la réponse du service. Pour une expression vide, vérifiez la structure et les noms techniques avant de changer le service appelé. Le dépannage par symptôme aide à choisir le bon contrôle.
Réessais et workflow de secours
Les paramètres du workflow permettent de stopper, de réessayer le workflow complet ou le nœud échoué, ou de lancer un autre workflow publié du même propriétaire. Les réessais du nœud sont épuisés avant la politique globale. Les tests de nœud et les exécutions partielles ignorent cette politique.
Choisissez le périmètre en fonction des effets déjà réalisés :
Le workflow de secours reçoit l’exécution en échec dans
input.payload.executionet les informations de l’appelant dansinput.source. Il démarre sans attendre sa fin ; l’exécution d’origine reste en échec.Approbation des outils d’agent
Un outil avec
requireApproval: truesuspend le workflow. Dans l’historique, une personne autorisée examine l’action et ses arguments, puis choisit Approuver et reprendre ou Refuser et reprendre. Un refus est transmis au modèle sans exécuter l’action refusée. La reprise restaure les messages et les outils déjà terminés, y compris après redémarrage.Chaque appel protégé demande sa propre décision. Cette pause nécessite un workflow complet, hors boucle, appel inline ou agent imbriqué. Pour répondre à une approbation, reprenez l’exécution concernée au lieu de lancer une nouvelle exécution complète.
Déclencheurs externes
Après publication, provoquez un événement réel et retrouvez l’exécution correspondante grâce à l’heure, au type de déclencheur et à un identifiant de test présent dans les données. Vérifiez sa fin et le résultat dans le service cible.
Un test avec payload simulé valide uniquement le traitement de cet exemple. Il ne vérifie pas le réseau, l’authentification entrante, les abonnements aux événements ou l’horaire planifié. Un webhook en réponse immédiate peut aussi répondre avant la fin du workflow.
Conservation de l’historique
Les offres prévoient des droits de conservation et de détail des exécutions. Consultez Tarifs et licences et votre offre active pour connaître les valeurs applicables. Pour une demande de support, relevez les informations nécessaires pendant qu’elles sont disponibles, en retirant les secrets et données personnelles.