Un lead attend une journée entière
Le formulaire arrive la nuit, le commercial le voit le matin. Entre-temps la personne a écrit à deux concurrents, et le clic que vous avez payé est perdu.
Posez le scénario sur le canevas : ce qui le déclenche, ce qui suit et où part le résultat — e-mail, requête HTTP, événement Meta CAPI, fiche de lead. Le bouton « Test » exécute le brouillon et affiche la sortie de chaque étape avant toute mise en service.
Le formulaire arrive la nuit, le commercial le voit le matin. Entre-temps la personne a écrit à deux concurrents, et le clic que vous avez payé est perdu.
Un script serveur que seul un développeur comprend casse au premier changement d’API, et plus personne ne sait pourquoi les événements n’arrivent plus.
L’automatisation « a l’air de marcher » jusqu’à ce qu’on remarque qu’aucun e-mail n’est parti depuis trois semaines. Sans historique, rien à analyser.
Un événement de données (lead ou campagne créés ou modifiés, conversion enregistrée), un calendrier, un webhook entrant ou un lancement manuel.
Quatorze types d’étapes : requête HTTP, e-mail, événement Meta CAPI, création, recherche, mise à jour et suppression de leads, filtre, branche, boucle, pause et étape IA.
Le bouton « Test » exécute le brouillon et montre ce que chaque étape a renvoyé. Tant que vous n’avez pas activé, le brouillon ne touche aucune donnée réelle.
Le déclencheur et les étapes forment un schéma relié : marketing et développement lisent la même logique sans ouvrir le code.
Événement de données, calendrier à la minute, webhook entrant signé ou lancement manuel : un workflow, plusieurs raisons légitimes de partir.
Filtres, branches si/sinon, boucle sur une liste et pause jusqu’au bon moment : le scénario encaisse des données réelles, pas idéales.
Les workflows créent, retrouvent et mettent à jour des fiches de lead, du statut nouveau à converti, sans CRM séparé pour le premier kilomètre.
Les événements leads, campagnes et conversions partent en JSON signé vers votre URL, et le journal de livraison montre tentatives et réponse du destinataire.
Chaque run affiche le statut par étape et le code d’erreur ; une étape en échec se rejoue jusqu’à trois fois ou se saute sans faire tomber le tout.
Non. Le déclencheur et les étapes se glissent sur le canevas et chaque étape se règle dans un formulaire. Une étape de code JavaScript existe, mais elle est activée par l’administrateur de l’installation et n’est pas nécessaire aux scénarios courants.
Quatre types de déclencheur : un événement de données (lead créé ou modifié, campagne créée ou modifiée, conversion enregistrée, lead Meta synchronisé), un calendrier, un webhook entrant en GET ou POST, et un lancement manuel depuis le constructeur.
Oui, c’est le rôle du bouton « Test » : il exécute le brouillon et le panneau des exécutions montre ce que chaque étape a renvoyé. Un brouillon n’est pas en service tant que vous n’avez pas cliqué sur Activer, donc les essais n’affectent pas la version en production.
Cela dépend du réglage de l’étape. Vous pouvez activer les reprises, qui lui accordent jusqu’à trois tentatives, ou laisser le workflow continuer en marquant l’étape comme échouée sans danger. Une exécution est plafonnée à dix minutes, puis s’arrête sur une erreur de délai.
De deux façons : une étape de requête HTTP dans le workflow, ou un webhook sortant qui poste du JSON signé vers votre URL sur les événements choisis. Le secret de signature s’affiche une seule fois et le journal conserve statut et nombre de tentatives.
Un brouillon se crée en une minute, se vérifie avec le bouton « Test » et ne passe en service que sur votre décision. Avant cela, il n’envoie aucun e-mail.