Flux de travail

Consulte les automatisations de workflow d'une installation : les workflows, le graphe complet d'un workflow, les types de nœuds qu'un graphe peut utiliser et des modèles sélectionnés. Consultez node_types avant de construire ou de modifier un graphe afin que chaque type et paramètre soit valide dans l'installation.

Actions :

• list : Lister les workflows. Chaque workflow avec son état actif ou non, sa version publiée, son nombre d'exécutions, sa dernière exécution et ses nœuds (id, name, type). Les workflows de marque et d'organisation ne sont pas listés.
• get : Obtenir un workflow. Le graphe brouillon complet (nœuds, connexions, notes, paramètres) et meta : active, publishedVersionId et, une fois publié, publishedWorkflow, le graphe actuellement actif. Uniquement les workflows de cette installation. Requiert workflowId.
• node_types : Types de nœuds. Entrées de la palette avec type, label, category, outputs (branches) et inputSchema, les paramètres à renseigner. available vaut false, avec la raison, lorsqu'il manque à l'installation un module dont le nœud a besoin. Les outils MCP apparaissent sous forme de nœuds mcp...
• templates : Modèles. Points de départ pour des automatisations courantes, avec risk et riskNote (ce qui peut mal tourner en cas de publication imprudente), les types de nœuds, les modules requis, la disponibilité dans cette installation et un graphe d'aperçu. Transformez-en un en graphe avec workflow_definitions_write instantiate_template.

Crée, modifie, publie, arrête et supprime les automatisations de workflow d'une installation. Boucle de création : consultez node_types avec workflow_definitions_read, construisez le graphe (ou partez de instantiate_template), créez-le comme brouillon, essayez-le avec workflow_runs_write test (simulé), puis publiez. Les modifications d'un brouillon ne changent jamais ce qui est actif tant qu'il n'est pas publié.

Actions :

• create : Créer un workflow. Enregistre un nouveau brouillon inactif à partir d'un graphe complet comportant au moins un nœud ; name vaut par défaut « Untitled workflow ». Les problèmes de validation sont renvoyés dans errors avec le détail des nœuds. Requiert nodes.
• update : Enregistrer le brouillon. Remplace tout le brouillon : envoyez chaque nœud et chaque connexion, pas seulement les modifications. Ce qui est actif continue de s'exécuter jusqu'à la publication. Les problèmes de validation sont renvoyés dans errors avec le détail des nœuds. Requiert workflowId, nodes.
• patch_meta : Renommer. Modifie uniquement le nom ou la description ; le graphe et ce qui est actif restent inchangés. changed vaut false lorsque les deux correspondent déjà. Requiert workflowId.
• duplicate : Dupliquer. Copie un workflow dans un nouveau brouillon nommé « (copy) » avec de nouveaux ids de nœuds, jamais publié ni actif. L'original reste inchangé. Requiert workflowId.
• delete : Supprimer. Supprime définitivement le workflow : brouillon, versions publiées, historique des exécutions et routage des déclencheurs. set_active false l'arrête mais le conserve ; discard_draft réinitialise seulement les modifications du brouillon. Requiert workflowId. Demande une confirmation.
• discard_draft : Abandonner les modifications du brouillon. Réinitialise le brouillon à la dernière version publiée, en supprimant les modifications faites depuis. La version active n'est jamais affectée ; requiert une version publiée. Requiert workflowId. Demande une confirmation.
• publish : Publier. Valide le brouillon, l'enregistre comme version active et active le workflow, de sorte que ses déclencheurs se déclenchent et que ses actions s'exécutent réellement. Les exécutions en cours se terminent sur l'ancienne version. Si des étapes Delay en attente devaient être replanifiées, le résultat comporte le code WAIT_RETARGET_CONFIRMATION_REQUIRED et impacts : appelez de nouveau avec confirmWaitRetargets et ces impacts. Requiert workflowId. Demande une confirmation.
• set_active : Activer ou désactiver. active true réactive un workflow publié. active false l'arrête : les déclencheurs ne se déclenchent plus et les étapes Delay en attente sont annulées, si bien qu'elles ne se terminent jamais. Rien n'est supprimé. Demande d'abord une confirmation, sauf s'il est déjà dans cet état. Requiert workflowId, active. Peut demander une confirmation.
• instantiate_template : Graphe à partir d'un modèle. Transforme un modèle en graphe prêt pour create : { name, description, nodes, connections } avec de nouveaux ids de nœuds. Les modèles laissent volontairement vides les destinataires, les portes et les heures ; renseignez-les d'abord. N'enregistre rien. Requiert templateId.
• generate : Générer un graphe. Construit un graphe à partir d'une consigne en langage courant avec l'IA de l'installation et renvoie { name, description, nodes, connections } en n'utilisant que des types de nœuds valides. Passez workflow pour en réviser un ; le graphe révisé complet est renvoyé. N'enregistre rien, mais consomme les crédits IA de l'installation. Requiert prompt. Demande une confirmation.

L'historique des exécutions d'un workflow, des plus récentes aux plus anciennes, et le détail étape par étape d'une exécution. Utilisez-le pour vérifier si une automatisation s'est exécutée, suivre une exécution lancée avec workflow_runs_write, ou trouver quel nœud a échoué et pourquoi.

Actions :

• list : Lister les exécutions. Chaque exécution avec son statut, son mode (live ou test), ses effets de bord, son déclencheur, qui l'a lancée, ses horaires, son nombre d'étapes, le nœud sur lequel elle attend et toute erreur. Requiert workflowId.
• get : Obtenir une exécution. Le statut de l'exécution ainsi que chaque étape dans l'ordre, avec l'entrée, la sortie, la note et l'erreur de chaque nœud. Les exécutions sont asynchrones : une exécution avec des Delays attend que sa suite arrive à échéance. Requiert workflowId, executionId.

Lance, teste, annule et rejoue des exécutions de workflow. Préférez test, qui exécute le brouillon avec des effets de bord simulés ; run exécute réellement le workflow publié. Les exécutions sont asynchrones : suivez-les avec workflow_runs_read get.

Actions :

• run : Exécuter maintenant. Exécute le workflow publié à partir de son déclencheur manuel (custom.manualTrigger), avec de véritables effets de bord. Les déclencheurs planifiés, webhook et d'événement se déclenchent d'eux-mêmes. Renvoie l'executionId de l'exécution et son premier statut. Requiert workflowId. Demande une confirmation.
• test : Tester le brouillon. Exécute le brouillon enregistré sans le publier, enregistré comme exécution de test. Les effets de bord sont simulés par défaut : rien n'est envoyé ni basculé, et chaque nœud indique ce qu'il aurait fait. sideEffects live demande d'abord une confirmation. Requiert workflowId. Peut demander une confirmation.
• cancel : Annuler une exécution en attente. Annule une exécution en attente sur un Delay : ses attentes en cours se ferment et les étapes suivantes ne s'exécutent jamais. Les exécutions terminées et celles en cours d'étape ne peuvent pas être annulées. Requiert workflowId, executionId. Demande une confirmation.
• retry : Rejouer une exécution. Rejoue une exécution terminée à partir de l'entrée de déclencheur enregistrée, liée via retryOf. published (par défaut) réexécute réellement la version utilisée et demande d'abord une confirmation ; draft-test exécute le brouillon actuel en simulation, le bon choix pendant la correction d'un échec. Requiert workflowId, executionId. Peut demander une confirmation.