Brouillon, version publiée et historique

Chaque workflow a deux faces : le brouillon, que vous modifiez dans l’éditeur, et la version publiée, celle que les déclencheurs exécutent réellement. Modifier ne change jamais ce qui tourne ; seule la publication le fait. Cette page explique comment le brouillon est enregistré, ce que la publication vérifie et fait, comment lire et reprendre les versions antérieures, et quelle version une exécution utilise.

Le graphe lui-même et la vérification à la publication sont décrits dans Workflows.

Brouillon et version publiée

Un workflow pointe vers au plus deux versions :

	Brouillon	Version publiée
Ce que c’est	le graphe que vous modifiez	le graphe qu’exécutent les déclencheurs
Évolue	à chaque modification	jamais : une version publiée est figée
S’exécute	seulement en essai	à chaque exécution réelle
Combien	un	au plus une à la fois

Une version est une copie numérotée du graphe (Version 1, Version 2…). Un nouveau workflow démarre avec un brouillon vide, la version 1. Tant que le brouillon n’a jamais été publié, l’enregistrer l’écrase et son numéro ne change pas. Publier fige le brouillon tel quel : la version garde son numéro et ne peut plus être modifiée. La modification suivante ouvre un nouveau brouillon, avec le numéro suivant.

Les numéros comptent donc des brouillons, pas des publications : « Version 4 » n’est pas forcément la quatrième publication, et le brouillon en cours a son propre numéro dans la liste.

Certains réglages appartiennent au workflow et non à une version, et changent sans republier : la pause, le rang utilisé par votre politique de déclenchement, l’URL de webhook et le workflow d’erreur.

L’enregistrement automatique

Il n’y a pas de bouton Enregistrer. L’éditeur enregistre le brouillon tout seul environ une seconde et demie après votre dernière modification. L’état s’affiche à côté du nom du workflow : « Modifications en attente… », « Enregistrement… », « Enregistré à {time} » ou « Échec de l’enregistrement ».

• L’enregistrement ne bloque jamais. Un brouillon qui contient des erreurs est enregistré quand même : un workflow en construction est rarement complet. Les erreurs ne bloquent que l’essai et la publication.
• Quitter la page déclenche un dernier enregistrement. S’il échoue, une fenêtre « Quitter sans enregistrer ? » propose « Réessayer l’enregistrement », « Rester sur la page » ou « Quitter sans enregistrer ».
• Deux éditeurs sur le même brouillon. Si le brouillon a été modifié ailleurs (un autre onglet ou un autre membre) depuis que vous l’avez ouvert, rien n’est écrasé : l’état affiche « Modifié ailleurs », l’enregistrement automatique s’arrête, et vous choisissez entre « Recharger sa version » et « Garder ma version » (qui écrase l’autre modification).

Par l’API, le brouillon se lit avec GET /api/v1/workflows/:id/draft et s’enregistre avec PUT /api/v1/workflows/:id/draft et un corps { "graph": { … } }. Ajoutez "expectedDraft": { "id": …, "updatedAt": … } (les valeurs rendues par la lecture précédente) pour que l’enregistrement soit refusé avec 409 workflow.draft_conflict si quelqu’un d’autre a écrit entre-temps.

Publier

Cliquez Publier dans l’éditeur. La fenêtre « Publier le workflow » affiche, dans l’ordre :

1. les erreurs bloquantes, s’il y en a : le bouton Publier reste désactivé tant qu’elles ne sont pas corrigées ;
2. Ce qui change : les différences avec la version en ligne, ou « Première publication : tout le workflow passe en ligne. » ;
3. Ce qui se passera une fois publié : une phrase par déclencheur, par exemple « « Mail reçu » se lancera à chaque nouveau mail qui correspond à ses conditions. » ou « une URL de webhook sera générée. Elle ne s’affichera qu’une fois, dans la fiche du déclencheur. » ;
4. les avertissements, qui ne bloquent pas.

Le bouton affiche « Publier » pour une première publication, « Publier les modifications ({count}) » quand le brouillon diffère de la version en ligne, et « Publié » (désactivé) quand il n’y a rien à publier.

Ce que vérifie le serveur, dans cet ordre :

Vérification	Refus
Le workflow est archivé	409 workflow.archived
Le brouillon a des erreurs bloquantes (les avertissements ne bloquent jamais)	422 workflow.not_publishable, avec la liste des erreurs
La politique de nœuds de l’organisation interdit un nœud du graphe	workflow.forbidden_node (voir Gouvernance)
Les nœuds workflow.call formeraient une boucle d’appels	422 workflow.call_cycle

Les erreurs et avertissements eux-mêmes sont listés dans Workflows, section « La vérification à la publication ».

Ce que fait la publication, d’un seul geste : elle fige le brouillon comme version publiée, puis arme les déclencheurs — les déclencheurs mail sur toutes les boîtes qui vous appartiennent et ne sont pas déconnectées, les planifications, les déclencheurs par sondage et l’URL de webhook. L’URL de webhook n’est générée qu’à la première publication : republier garde la même URL. Un workflow en pause le reste après la publication (« il le restera après la publication. Reprenez-le pour qu’il se déclenche. »).

Par l’API : POST /api/v1/workflows/:id/publish. La réponse porte ok, validation, publishedVersion, armedMailboxes et, pour un workflow webhook publié pour la première fois, l’URL de webhook et son jeton.

Ce qui a changé depuis la publication

Quand le brouillon diffère de la version en ligne, l’éditeur affiche un badge Modifications non publiées. Cliquez-le (« Voir ce qui a changé ») pour lister les différences :

Différence	Affichée ainsi
Un nœud a été ajouté	Nœud ajouté : {name}.
Un nœud a été supprimé	Nœud supprimé : {name}.
Un nœud a été renommé	Nœud renommé : {name}.
Les réglages d’un nœud ont changé	Réglages modifiés : {name}.
Les liens entre nœuds ont changé	Les liens entre nœuds ont changé.

Déplacer un nœud sur le canvas ne compte pas comme une modification. La même comparaison apparaît dans la fenêtre de publication, sous « Ce qui change ».

La liste des workflows affiche aussi « Modifications non publiées » à côté d’un workflow dont le brouillon a été enregistré depuis la dernière publication. Ce badge-là se fonde sur l’enregistrement, pas sur la comparaison ci-dessus : il peut apparaître alors que vous n’avez fait que déplacer un nœud, et que l’éditeur ne montre aucune différence.

Le panneau Versions

Ouvrez Versions depuis le menu « ⋯ » de l’éditeur. Le panneau liste les versions du workflow, la plus récente d’abord — au plus les 50 dernières —, avec :

• le numéro (« Version {number} ») ;
• une date : « Publiée le {date} » pour une version publiée, « Brouillon modifié le {date} » pour le brouillon ;
• un badge : En ligne pour la version qu’exécutent les déclencheurs, Brouillon en cours pour le brouillon que vous modifiez.

Dépliez une version pour la comparer au brouillon actuel : « Identique au brouillon actuel. », ou « Reprendre cette version changerait {count} éléments : » suivi des différences, dans les mêmes termes que ci-dessus. Une version ne se compare qu’au brouillon actuel, pas à une autre version.

Une version n’enregistre ni auteur ni commentaire.

Par l’API : GET /api/v1/workflows/:id/versions liste les versions (id, number, publishedAt — null pour le brouillon —, createdAt, updatedAt), et GET /api/v1/workflows/:id/versions/:versionId/graph rend le graphe figé d’une version.

Reprendre une version antérieure

Reprendre comme brouillon recopie une version antérieure dans le brouillon. Ce geste ne publie jamais rien : la version en ligne continue de tourner jusqu’à votre prochaine publication.

1. Ouvrez Versions depuis le menu « ⋯ ».
2. Dépliez la version voulue et vérifiez ce qui changerait.
3. Cliquez Reprendre comme brouillon, puis confirmez. La fenêtre prévient : « Le brouillon actuel est remplacé par cette version, et ses modifications non publiées sont perdues. La version en ligne ne change pas tant que vous ne publiez pas. »
4. Vérifiez le brouillon repris, lancez un essai si besoin, puis Publiez.

Le bouton est désactivé quand la version est identique au brouillon, et sur un workflow archivé. Dans l’éditeur, la reprise vide aussi l’historique des annulations.

Revenir en arrière sur un workflow en ligne se fait donc en deux temps : reprendre la version antérieure comme brouillon, puis la publier. Elle passe en ligne sous un nouveau numéro de version ; l’historique garde toutes les versions.

Par l’API : POST /api/v1/workflows/:id/versions/:versionId/restore. Elle remplace le brouillon sans contrôle de concurrence, et rend le nouveau brouillon avec sa validation. Sur un workflow archivé, elle répond 409 workflow.archived.

La version qu’utilise une exécution

Chaque exécution est liée à la version sur laquelle elle a démarré, et la garde jusqu’au bout :

• Republier ne change rien aux exécutions en cours. Une exécution démarrée sur la version 3 se termine sur la version 3, même si la version 5 est publiée entre-temps. Cela vaut aussi pour les exécutions qui reprennent plus tard : après une attente ou une approbation, les étapes suivantes utilisent toujours le graphe de la version 3.
• Les nouvelles exécutions utilisent la version publiée au moment où elles démarrent. Un mail qui arrive après la publication exécute la nouvelle version.
• Une exécution par mail et par version. Un même mail ne lance jamais deux fois la même version publiée. Une autre version est une autre version : republier peut traiter de nouveau un mail que la version précédente avait déjà vu, s’il est livré de nouveau.
• Les lancements manuels depuis le webmail (« Lancer un workflow ») utilisent toujours la version publiée du moment.
• Les sous-workflows appelés avec Appeler un workflow exécutent la version du workflow appelé publiée au moment de l’appel.
• Rejouer une exécution en échec (voir Gestion des erreurs et rejeu) n’est possible que tant que la version sur laquelle elle a tourné est encore la version publiée. Après une republication ou une mise hors ligne, le rejeu est refusé avec execution.version_unavailable.

Mettre en pause, mettre hors ligne, archiver

Action	Où	Déclencheurs	Version publiée	Exécutions en cours
Mettre en pause / Reprendre	éditeur	aucune nouvelle exécution ne part des mails, planifications ou sondages ; rien n’est désarmé	inchangée	se terminent
Mettre hors ligne	éditeur, menu « ⋯ »	tous désarmés : plus aucun mail, appel de webhook ni planification ne le lance	retirée ; le workflow s’affiche Brouillon	se terminent
Archiver / Désarchiver	liste des workflows	tous désarmés ; désarchiver ne réarme rien	retirée	se terminent
Supprimer	liste des workflows	—	—	—

• Mettre hors ligne ouvre une fenêtre qui propose « Mettre en pause à la place » : une pause s’annule d’un clic sur Reprendre, alors qu’un workflow mis hors ligne doit être publié de nouveau. Dans les deux cas, « les exécutions déjà en cours vont jusqu’au bout. »
• Un workflow archivé ne peut être ni publié ni repris dans une version antérieure. Désarchivez-le depuis la liste des workflows, puis publiez-le de nouveau.
• Supprimer n’est possible que pour un workflow jamais publié et qui n’a jamais tourné. Sinon, le serveur refuse avec workflow.delete_forbidden : archivez-le plutôt.
• Aucune de ces actions n’annule une exécution déjà en cours. Pour retenir les mails sur le point de partir, un administrateur peut couper les envois de toute l’organisation (voir Gouvernance).

Le statut affiché dans la liste des workflows est, par priorité : Archivé, En pause, Publié, Brouillon. Les anciennes versions ne sont jamais purgées : elles ne disparaissent qu’avec le workflow lui-même.

Dupliquer, importer et exporter

• Dupliquer (liste des workflows, ou menu « ⋯ » de l’éditeur) crée un nouveau workflow, « Copie de {name} », à partir du brouillon de la source — pas de sa version en ligne. La copie est un brouillon jamais publié. Elle ne reprend ni les exécutions, ni les mails d’essai, ni l’URL de webhook de la source. Par l’API : POST /api/v1/workflows/:id/duplicate avec { "name": … }.
• Il n’y a pas d’import ni d’export de fichier dans l’éditeur. Par l’API, lisez un graphe avec GET /api/v1/workflows/:id/draft (ou le graphe d’une version), et créez un workflow à partir d’un graphe avec POST /api/v1/workflows, dont le corps accepte un graph facultatif. Le graphe est rattaché au nouveau workflow et à sa première version. Voir la référence de l’API.

Pages liées

• Workflows
• Essais
• Exécutions
• Gestion des erreurs et rejeu