Flux de contrôle : gates, branches et boucles

Les nodes font le travail ; le flux de contrôle décide quels nodes tournent, quand, et sous quelle approbation. Les tuiles que vous insérez vivent dans la section Structural (« Structurels ») de la palette — glissez une tuile sur le canvas, ou cliquez dessus pour l'ajouter (l'éditeur). Les tuiles : Trigger (« Déclencheur »), Approval Gate (« Porte d'approbation »), Workflow Reference (« Référence de workflow »), Branch / Switch (« Branche / Switch »), For Each (« Pour chaque »), Map / Fan-out (« Map / Distribution »), les deux tuiles d'attente — Wait (timer) (« Attente (minuteur) ») et Wait (event) (« Attente (événement) ») — et Comment (« Commentaire »), un cadre d'annotation titré qui décrit une région du graphe et ne s'exécute jamais. Cette page couvre les blocs de décision et de répétition ; Workflow Reference — intégrer un autre workflow — est couvert dans Anatomie, et Trigger relève des déclencheurs, dans le cycle de vie.

Une règle façonne tout le reste ici : tout chemin vers une écriture passe par une gate. Le validateur l'impose — vous ne pouvez pas publier un graphe où un node qui écrit est atteignable sans une décision humaine placée devant lui.

Gates

Une gate met le run en pause et vous demande de décider. Vous donnez à chaque gate un label et des instructions — le texte que lit le décideur quand la gate se déclenche. Pendant qu'elle attend, la gate figure dans votre file de décisions (Décisions).

Une gate peut capturer des données, pas seulement une approbation. Ajoutez des champs typés — String, Number, Bool, Json ou Enum — et les valeurs saisies par le décideur sortent de la gate sur son pin response, disponibles pour tous les nodes en aval.

Pour les décisions d'aiguillage, donnez à la gate des décisions nommées : chacune devient un bras sortant étiqueté en langage humain (« On expédie » / « À retravailler »), et le run continue sur le bras que le décideur choisit.

Une gate peut porter un timeout. Si personne ne décide à temps, la gate fait ce que vous avez choisi à l'écriture : faire échouer l'étape, ou la sauter et continuer. Aucune gate ne s'approuve jamais elle-même — l'auto-résolution est un opt-in par gate que vous configurez délibérément, jamais un défaut (gouvernance).

Branch

Branch — la tuile Branch / Switch (« Branche / Switch ») — aiguille sur des données plutôt que sur un humain. Vous écrivez une liste ordonnée de cas ; à l'exécution, le premier cas qui correspond gagne, et le run continue sur le bras de ce cas. Un cas correspond de deux façons : donnez-lui une valeur à comparer au sélecteur câblé, ou donnez-lui une expression — une règle booléenne — et ce cas devient un bras Switch, qui route par règle plutôt que par valeur. Chaque Branch a exactement un bras else pour tout ce qui ne correspond pas. Une fois les bras divergés, ils restent séparés — voir les règles du validateur ci-dessous.

Loop

Loop répète une étape jusqu'à ce que son résultat soit accepté, avec un maximum de 10 tentatives. C'est un bloc hérité : retiré pour les nouvelles créations, vous ne trouverez donc pas de tuile Loop dans la section Structural. Les workflows publiés qui en contiennent un tournent toujours, inchangés. Pour tout ce que vous créez aujourd'hui, prenez ForEach ci-dessous.

Fan-out en parallèle (MapFanOut)

MapFanOut — la tuile Map / Fan-out (« Map / Distribution ») — exécute le même corps une fois par élément d'une liste, en parallèle. Vous le pointez sur un pin source — la sortie amont qui porte la liste —, vous nommez la variable d'élément que lit le corps, et il déploie jusqu'à 1000 éléments.

Le corps est volontairement petit : une seule étape du catalogue, ou un sous-workflow quand une étape ne suffit pas (Anatomie couvre les sous-workflows). La forme naturelle tient en trois nodes : une étape de préparation qui charge la liste, le corps par élément, et une étape de réduction qui agrège les résultats. Les éléments tournent normalement indépendamment ; si certains doivent en attendre d'autres, déclarez des dépendances entre éléments frères et le fan-out s'exécute comme un petit graphe de dépendances plutôt qu'une mêlée.

Fan-out un par un (ForEach)

ForEach — la tuile For Each (« Pour chaque ») — parcourt la même liste un élément à la fois, dans l'ordre, et permet de sortir en avance dès qu'une condition est remplie.

Son corps prend deux formes, mutuellement exclusives :

• Corps intégré — une étape du catalogue (ou un sous-workflow) exécutée une fois par élément, avec une condition d'arrêt optionnelle vérifiée entre les éléments.
• Région Loop Body — câblez le Loop Body de la tuile vers un petit sous-graphe multi-étapes fait d'étapes simples du catalogue, avec un Branch qui pilote le pin Break vivant quand il faut s'arrêter tôt. Vous obtenez un vrai corps multi-étapes sans détacher un sous-workflow ; imbriquer d'autres tuiles structurelles dans la région reste rejeté.

Lequel choisir ? MapFanOut quand les éléments sont indépendants et que vous voulez du débit. ForEach quand l'ordre compte, quand chaque élément doit voir les effets du précédent, ou quand vous voulez vous arrêter dès qu'un élément réussit.

Wait

Deux tuiles, deux comportements :

• Wait (timer) (« Attente (minuteur) ») met le run en pause pour une durée fixe — de 1 minute jusqu'à 28 jours.
• Wait (event) (« Attente (événement) ») met le run en pause jusqu'à ce que quelque chose se produise ailleurs dans la plateforme. Six types d'événements sont actifs : mission.created, conversation.completed, support-case.created, incident.created, batch.completed, mr.merged.

Finally

Finally sert au nettoyage — libérer un bail, clore un workspace, poster un résumé. Quoi qu'il enveloppe, le nettoyage s'exécute exactement une fois, que le flux environnant réussisse, échoue ou soit annulé. Utilisez-le quand une étape acquiert quelque chose qui ne doit pas fuir.

Une réserve : Finally n'a pas de tuile dans la palette. Aujourd'hui, il se rédige dans le payload du graphe lui-même — le chemin d'authoring agent/MCP — et ne se place pas depuis l'éditeur.

Les règles qu'applique le validateur

Quand vous publiez un draft avec Publish (« Publier ») — ou que vous exécutez les mêmes contrôles à blanc avec l'outil workflow_validate_draft — tout est vérifié d'un coup et chaque problème est signalé ensemble (cycle de vie). Pour le flux de contrôle, trois règles comptent le plus :

• Les bras restent isolés. Les cas d'un Branch, les décisions nommées d'une gate et les bras d'issue (Anatomie) ne reconvergent jamais en aval. Un bras qui ne mène nulle part est une impasse valide, pas une erreur.
• Les corps de fan-out restent plats. Un corps de MapFanOut est une étape du catalogue ou un sous-workflow ; un corps de ForEach est cela — ou une région Loop Body câblée d'étapes simples. Dans tous les cas, impossible d'imbriquer davantage de contrôle structurel dans le corps lui-même. Besoin de plus ? Mettez-le dans un sous-workflow.
• La dominance des gates. Tout chemin de dépendance vers un node qui écrit doit traverser une gate. Si une route contourne la gate et atteint une écriture, la publication est refusée et la liste de problèmes la nomme.