monday.com Workflow Builder : le guide 2026 du Créateur

Le Workflow Builder de monday.com est un canvas visuel de type node-based (pensez à un Figma pour automations) qui remplace l’éditeur texte « When this happens → Then do that » hérité de 2019. Sorti en bêta publique en juin 2024 et passé en disponibilité générale le 4 février 2025, il a reçu trois itérations majeures jusqu’en mars 2026 : blocs cross-board, conditions multi-critères, et ouverture aux déclencheurs Salesforce et HubSpot en natif.

Cet article répond à une seule question : comment construire, migrer et exploiter des workflows dans le nouveau Builder ? On ne parle ici ni des Blocs IA (voir article dédié), ni d’Agent Factory (voir article dédié), ni de monday service. Juste le moteur de workflow.

Qu’est-ce que le Workflow Builder de monday.com ?

Le Workflow Builder est l’éditeur visuel natif de monday.com pour créer des automations multi-étapes, multi-boards, et conditionnelles via un canvas où chaque bloc représente un déclencheur, une condition, un délai ou une action.

Le Workflow Builder de monday.com est un canvas visuel qui remplace l’éditeur « When this happens » : on y assemble déclencheurs, conditions et actions par glisser-déposer, avec support cross-board et intégrations natives Salesforce, Slack, HubSpot.

Ethanolle

Concrètement, on passe d’une liste de recettes linéaires (« When status changes to Done, then notify Léo ») à un graphe orienté : un déclencheur en entrée, des embranchements conditionnels, des actions qui peuvent elles-mêmes déclencher d’autres conditions. L’analogie technique la plus proche est un workflow n8n ou Zapier, mais entièrement intégré au graphe de données monday.

Ce que le Builder change concrètement pour les équipes Ops :

• • Visibilité. Un workflow complet tient sur un écran. On voit les branches mortes, les conditions qui ne matchent jamais, les actions orphelines.
• • Multi-actions sur un seul déclencheur. Un changement de statut peut déclencher en parallèle une notification Slack, un item créé sur un autre board, et une mise à jour Salesforce, sans empiler trois automations séparées.
• • Conditions composables. Les If/Else sont des blocs de première classe, pas une option cachée dans une recette.
• • Logs et debug. Chaque exécution produit une trace visuelle par bloc. Les anciennes automations donnaient juste un log texte opaque.

Qu’est-ce que le Workflow Builder remplace exactement ?

Le Workflow Builder remplace le module « Automations » classique (recettes « When this happens → Then do that ») pour la création de nouveaux flux, mais laisse vivre les automations existantes sans migration forcée.

Le logiciel monday a été explicite sur la compatibilité : aucune recette existante n’est cassée. Les automations legacy continuent d’apparaître dans l’onglet « Automations » de chaque board. Ce qui change :

• • Tout nouveau type de bloc est exclusif au Builder. Les déclencheurs Salesforce Object, les conditions multi-critères, les blocs Move item to board conditionnels, les délais programmables à la minute près, aucun n’est accessible depuis l’ancien éditeur.
• • Les templates d’automation restent consultables, mais poussent vers le Builder dès qu’on clique sur Customize.

• Les intégrations tierces (Slack, Teams, Gmail, Salesforce, HubSpot, Jira) sont toutes exposées comme blocs dans le Builder. Les recettes tierces héritées tournent toujours, mais les nouvelles versions d’intégration (ex. Slack create channel sorti en janvier 2026) ne vivent que côté Builder.

En pratique, chez nos clients, la question n’est plus « dois-je migrer ? » mais « quels workflows méritent d’être refondus maintenant vs. laissés tels quels jusqu’à fin de vie naturelle ? »

Comment construire un workflow : anatomie d’un canvas

Un workflow dans le Builder se compose toujours d’un déclencheur unique (trigger) suivi d’un graphe de blocs : conditions, actions, délais, branches cross-board. On construit en glissant des blocs depuis le panneau latéral vers le canvas.

Les six familles de blocs

Le workflow minimal, pas à pas

1. Ouvrir l’onglet Workflows d’un board (ou d’un workspace pour un workflow cross-board pur).
2. Cliquer Create workflow. Le canvas apparaît, vide sauf une ancre « Add trigger ».
3. Choisir un déclencheur : par exemple « When status changes to Done ».
4. Glisser une condition : « Only if priority is High ».
5. Glisser deux actions en parallèle : « Notify account manager » et « Create item in Invoicing board ».
6. Nommer le workflow, activer.

À chaque sauvegarde, monday exécute un linter silencieux : blocs non connectés, conditions contradictoires, boucles infinies potentielles sont signalés avant activation. C’est nouveau par rapport aux automations classiques, où une recette cassée ne se révélait qu’à l’exécution.

Un workflow vraiment adapté

Nous construisons vos workflows avec vous pour aller plus vite et éviter les erreurs.

Déclencheurs disponibles en mars 2026

• Board events : item created, column changed, subitem added, item moved, item deleted.
• Time events : date arrives, every X days/weeks, every workday at HH:MM.
• Form events : form submitted, avec accès direct aux champs dans les blocs suivants.
• Integration triggers : Salesforce object created/updated, HubSpot deal stage changed, Gmail label received, Slack reaction added, Jira issue transitioned.
• Manual triggers : Run workflow on button click, utile pour des workflows one-shot déclenchés par l’utilisateur final.

Workflows cross-board : la vraie rupture avec l’ancien système

Le Workflow Builder permet nativement de déclencher sur un board et d’agir sur un autre, sans passer par une intégration Make ou Zapier externe, ce que les automations classiques ne faisaient qu’à moitié.

Un workflow cross-board monday.com déclenche sur un board A et agit sur un board B (créer un item, mettre à jour une colonne, déplacer) via un bloc natif, sans outil tiers ni mirroring manuel.

Ethanolle

Exemple type que nous déployons chez nos clients Sales Ops : un deal passe au statut Won dans le board CRM → un workflow crée automatiquement un item dans le board Onboarding avec les colonnes connectées pré-remplies (client, ARR, CSM assigné), puis un sous-item par étape du playbook d’onboarding, puis une notification au CSM et au finance ops. Un workflow, trois boards touchés, zéro Zap externe.

Les actions cross-board disponibles :

• • Create item in board avec mapping de colonne à colonne, y compris colonnes people, status, date, numbers et dropdown.
• • Move item to board : transfert complet avec historique et updates préservés.
• • Update item in board : cible un item existant par ID ou par match sur une colonne clé.
  • Mirror columns : synchronise en temps réel une colonne entre deux boards (utile pour propager un statut projet vers un board portfolio).

Limite à connaître : un workflow ne peut modifier que des boards auxquels l’utilisateur qui l’a créé a accès en écriture. Si un admin quitte l’organisation et que son workflow pointe sur un board privé, le workflow casse. Moralité : les workflows critiques sont créés par un compte de service ou un compte admin pérenne.

Migrer les automations legacy : le framework ICP

Pour migrer des automations existantes vers le Workflow Builder, nous utilisons chez Ethanolle le framework ICP (Intention → Cascade → Preuve) : regrouper par intention métier, cascader les actions dans un workflow unique par intention, puis prouver l’équivalence fonctionnelle par test avant bascule.

Un workflow cross-board monday.com déclenche sur un board A et agit sur un board B (créer un item, mettre à jour une colonne, déplacer) via un bloc natif, sans outil tiers ni mirroring manuel.

Ethanolle

I : Intention

On ne migre pas « la recette n°47 qui notifie Léo ». On migre l’intention « tenir l’équipe Sales informée des deals à risque ». Cette intention est souvent dispersée sur 3, 5, parfois 10 automations legacy écrites à des dates différentes par des personnes différentes.

Sur un compte de 147 automations chez un client ETI en février 2026, l’inventaire par intention a produit 52 intentions distinctes. C’est cette consolidation qui fait gagner 60 à 70 % de volume sans retirer de fonctionnalité.

C : Cascade

Dans le Builder, une intention devient un seul workflow avec embranchements. Exemple, « Deal à risque » :

• Trigger : status change to At risk ou probability < 30 % après 14 jours sans update.
• Condition 1 : si ARR > 50 k€, notifier le Head of Sales en plus.
• Condition 2 : si compte stratégique (colonne dropdown), créer un item dans le board Executive reviews.
• Action par défaut : tagger le deal, créer un sous-item de check-up, notifier le AE.

L’ancienne version : 4 à 6 recettes séparées qui se marchent parfois dessus (doubles notifications, ordre d’exécution non garanti).

P : Preuve

Avant de désactiver les automations legacy, on laisse les deux systèmes tourner en parallèle pendant 7 à 14 jours, avec les nouveaux workflows en mode dry run (action = notification de test au lieu de l’action réelle). On compare les logs. Quand 100 % des événements produisent le même output sur deux semaines, on bascule.

Chiffre concret : sur les 14 migrations que nous avons menées entre mars 2025 et mars 2026, la moyenne est de 2,8× moins de workflows pour la même couverture fonctionnelle, avec un temps de debug divisé par 4 (mesuré en tickets support interne résolus par semaine).

Intégrations : Slack, Salesforce, HubSpot comme blocs natifs

Les intégrations natives (Slack, Salesforce, HubSpot, Teams, Gmail, Jira) sont exposées comme des blocs de première classe dans le Workflow Builder, avec authentification OAuth partagée au niveau du workspace.

Pattern 1 : Lead routing Salesforce → monday. Un objet Lead créé dans Salesforce déclenche la création d’un item dans un board monday Inbound pipeline, avec mapping des champs (name, company, source, owner). Côté Builder, c’est un trigger Salesforce Object Created + une action Create item in board avec mapping visuel.

Pattern 2 : Onboarding client avec Slack auto-provisioning. Un deal Closed Won déclenche un workflow qui crée un channel Slack dédié via le bloc Slack: Create channel, invite les bonnes personnes, poste un message de bienvenue, et archive le channel 90 jours après Onboarded = true. Ce bloc Slack: Create channel est sorti en janvier 2026 et n’est disponible que dans le Builder.

Pattern 3 : Sync bidirectionnel HubSpot. Changement de stage côté HubSpot → update de la colonne statut du deal correspondant côté monday, et inversement. La difficulté étant de casser les boucles (update HubSpot → update monday → update HubSpot → …). Dans le Builder, un bloc condition changed by integration permet de court-circuiter la boucle côté déclencheur monday.

Limite à connaître : les quotas d’action monday s’appliquent par workflow par mois, selon le plan. Un workflow cross-board qui tourne 10 000 fois par mois sur un compte Standard saturera rapidement. À vérifier dans la page Usage du workspace avant déploiement massif. Pour le détail des quotas par plan, voir l’article dédié aux tarifs monday.com.

Limites actuelles et pièges à éviter

Le Workflow Builder n’est pas une solution universelle et présente en mars 2026 quatre limites concrètes à prendre en compte avant de migrer en masse.

1. Pas de récursion explicite ni de loops : On peut itérer sur des sous-items via l’action Run on each subitem, mais il n’existe pas de bloc For each généraliste sur une collection arbitraire. Pour un traitement par batch, on reste sur un appel API externe ou un outil comme Make.
2. Pas de scripting inline : À la différence de n8n ou de Zapier Paths avec code, le Builder n’autorise pas de bloc JavaScript ou Python. Toute logique non exprimable en blocs doit sortir vers un webhook et une fonction externe.
3. Debugging perfectible sur les workflows volumineux : Au-delà de 15 blocs, le canvas devient difficile à lire. Pas encore de zones ou groupes pour structurer un workflow complexe (la feature est sur la roadmap publique monday, trimestre non engagé).
4. Permissions fines manquent : On définit un créateur et un propriétaire, mais pas de granularité « cet utilisateur peut éditer la branche Sales, pas la branche Finance ». Pour des workflows multi-équipes sensibles, on fragmente.

Le piège le plus fréquent chez les clients qui découvrent le Builder : vouloir reproduire un workflow Make ou n8n complexe tel quel. Le Builder est excellent pour les workflows orientés objets monday. Dès que la logique devient algorithmique (transformations de données, appels API chaînés avec reshape), on sort de son terrain. Pour choisir l’outil externe qui prendra le relais, notre comparatif n8n vs Make détaille les prix et les limites de chacun.

FAQ : Workflow Builder monday.com

Quand monday.com va-t-il forcer la migration des anciennes automations ?

Aucune date de fin de vie n’a été annoncée par monday en avril 2026. Les recettes classiques restent créables et exécutables. La migration reste une décision d’hygiène, pas une contrainte calendaire. Les équipes produit monday ont confirmé lors de l’événement Elevate 2025 que l’intention n’est pas de casser les automations existantes.

Le Workflow Builder est-il disponible sur tous les plans monday ?

Oui, depuis février 2025 le Builder est accessible dès le plan Standard, avec des quotas d’actions mensuelles qui augmentent sur Pro et Enterprise. Les blocs d’intégrations premium (Salesforce, HubSpot) restent réservés au plan Pro et au-dessus, comme les anciennes recettes équivalentes.

Peut-on exporter ou versionner un workflow ?

Pas nativement dans l’interface en mars 2026. Un workflow peut être dupliqué dans le même workspace et exporté en JSON via l’API GraphQL de monday. Aucune intégration Git native. Pour un versioning propre sur un compte sensible, on maintient un export JSON périodique hors-plateforme.

Un workflow peut-il appeler un autre workflow ?

Indirectement. Un workflow A peut déclencher une action (création d’item, changement de statut) qui sert de trigger à un workflow B. La chaîne fonctionne, mais il n’y a pas d’appel explicite de type run workflow X entre deux canvas. Cette limite pousse à concentrer une intention dans un seul workflow plutôt qu’à découper.

Quelle est la différence entre Workflow Builder et Blocs IA ?

Le Workflow Builder est le canvas et le moteur d’exécution. Les Blocs IA (AI Blocks) sont une famille de blocs spécifique qui vit dans ce canvas et permet d’appeler un LLM (résumé, classification, extraction). Les Blocs IA font l’objet d’un article dédié sur le blog Ethanolle.

Le Workflow Builder remplace-t-il Make ou Zapier ?

Pour les workflows qui restent dans l’écosystème monday ou qui touchent les intégrations natives (Slack, Salesforce, Gmail, HubSpot, Teams, Jira), oui, dans la majorité des cas. Pour les workflows multi-SaaS complexes ou nécessitant du code, Make et Zapier restent pertinents en complément.

À propos d’Ethanolle

Ethanolle est l’agence partenaire Gold de monday.com basée à Paris. Nous déployons monday pour des entreprises de toute taille depuis 2024 : cadrage, configuration, migration, formation. Sur les 14 migrations Workflow Builder menées entre mars 2025 et mars 2026, le framework ICP est notre standard interne. 

Contact : ethanolle.com.