Multi-étapes et délais
Un flux de travail à une action est rarement intéressant. La vraie valeur est dans le séquençage — envoyer un message de bienvenue maintenant, attendre 3 jours, vérifier s'ils sont revenus, envoyer un suivi, attendre une semaine, passer le relais à un berger. Les flux de travail multi-étapes font exactement cela.
Séquentiel vs parallèle
La plupart des flux de travail sont séquentiels — action 1, puis action 2, puis action 3. Vous les construisez en connectant la poignée du bas d'une action à la poignée du haut de la suivante.
Lorsque vous devez exécuter plusieurs branches en même temps (ex. envoyer WhatsApp et mettre à jour un champ personnalisé simultanément), utilisez un nœud split. Les deux branches démarrent immédiatement lorsque le split est atteint.
TIP
Les splits finissent par se rejoindre via le flux normal — il n'y a pas de nœud « join » explicite. Chaque branche se termine indépendamment.
Délais
L'action wait_delay met l'exécution en pause pour une durée spécifiée. Modèles courants :
| Modèle | Pourquoi |
|---|---|
wait_delay 1 heure après la bienvenue | Laisser le nouveau membre s'installer avant le prochain message |
wait_delay 7 jours pour le deuxième contact | Cadence de suivi des nouveaux arrivants |
wait_delay 30 jours puis vérifier l'engagement | Étape de discipulat |
Les délais sont stockés dans la base de données, pas conservés en mémoire — donc un délai peut durer des jours ou des semaines sans consommer de ressources. Quand le délai s'écoule, l'exécution reprend là où elle s'était arrêtée.
Wait-until
Pour des moments calendaires spécifiques (ex. attendre jusqu'au prochain dimanche 9 h), utilisez wait_until avec une expression de date. C'est conscient du fuseau horaire — il utilise le fuseau horaire de votre église, pas UTC.
Un usage courant est la bienvenue arrive mardi à 10 h quel que soit le moment où ils se sont inscrits, ainsi les membres qui s'inscrivent samedi ne reçoivent pas un message au milieu du service du dimanche.
Wait-event
wait_event met en pause jusqu'à ce qu'un autre événement se déclenche pour le même sujet. Ex. un flux de travail peut attendre le prochain événement attendance.marked pour le membre avant de continuer. Utile pour « s'ils reviennent dans les 30 jours, faire X ; sinon, faire Y ».
Il prend aussi en charge un délai d'expiration — si l'événement ne se déclenche pas dans la période d'attente, l'exécution prend une branche de repli.
Ramification conditionnelle
L'action condition évalue un booléen et achemine vers vrai / faux. Vous pouvez enchaîner plusieurs conditions pour construire des flux complexes.
Pour une ramification à plusieurs voies (plus de deux résultats), utilisez split avec des conditions sur chaque branche, ou enchaînez les conditions en série.
Boucle
for_each itère sur une liste. La liste vient habituellement d'une action find_members_by_segment plus tôt dans le flux de travail.
À l'intérieur de la boucle, chaque action s'exécute une fois par élément. L'élément courant est disponible comme {{loop.current}} et l'index comme {{loop.index}}.
WARNING
Les boucles sur des segments très larges (milliers de membres) peuvent prendre du temps. Intégrez un petit wait_delay entre itérations pour éviter de saturer vos fournisseurs de messagerie.
Ordre FIFO
Au sein d'une seule exécution, les actions s'exécutent dans l'ordre du graphe. Entre exécutions, GCM les traite en FIFO — premier déclenché, premier exécuté. Il n'y a pas de file prioritaire.
C'est important quand un déclencheur à fort volume comme attendance.marked se déclenche pour des centaines de membres pendant un service du dimanche : l'exécution du flux de travail de chaque membre est mise en file, et elles se traitent dans l'ordre où la présence a été marquée.
La séparation async-vs-sync
GCM sépare les exécutions de flux de travail en deux chemins d'exécution :
- Synchrone — actions qui se terminent en millisecondes (set variable, update member, condition). Elles s'exécutent immédiatement quand l'action est atteinte.
- Asynchrone — actions qui bloquent (wait_delay, wait_event, send_message) ou appellent des services externes lents. Elles sont planifiées dans une file et reprises plus tard.
Vous n'avez pas à y penser — le constructeur s'en occupe pour vous. Mais c'est pourquoi une exécution avec trois étapes wait_delay peut rester en attente pendant des semaines sans aucun traitement actif.
Exemple détaillé : séquence de bienvenue
Un flux de travail typique pour nouveaux arrivants :
- Déclencheur —
member.createdoù le type d'adhésion est Visiteur. - Attendre 1 heure.
- Envoyer un message — bienvenue WhatsApp.
- Attendre 7 jours.
- Condition — le membre a-t-il assisté à une réunion depuis l'enregistrement ?
- Branche vraie — envoyer un message « content de vous revoir ».
- Branche fausse — envoyer un message « invitation à nous rejoindre dimanche ».
- Attendre 30 jours.
- Envoyer une notification — au berger approprié : « Il est temps de faire un suivi personnel avec ce nouveau venu ».
L'ensemble prend environ 5 minutes à construire dans le constructeur visuel. Voir Flux de travail de suivi des nouveaux arrivants pour la marche à suivre complète.
Reprise
Si GCM est redémarré pendant qu'une exécution est en cours, l'exécution reprend là où elle s'était arrêtée — aucune action n'est répétée, aucune action n'est sautée. L'état est persisté en base de données à chaque frontière d'étape.
Questions courantes
Un wait_delay peut-il durer éternellement ? Le maximum est 365 jours. Pour des cycles plus longs, enchaînez plusieurs flux de travail.
Puis-je éditer un flux de travail pendant que des exécutions sont en cours ? Oui — les exécutions en cours continuent avec la version avec laquelle elles ont démarré. Les exécutions nouvellement déclenchées utilisent la nouvelle version.
Puis-je annuler une exécution bloquée ? Oui — ouvrez l'exécution sur la page de suivi et cliquez sur annuler. Les actions restantes sont sautées.
Prochaines étapes
- Suivi des exécutions — déboguer ce qui s'est passé.
- Flux de travail de suivi des nouveaux arrivants — recette multi-étapes complète.
- Actions — le catalogue complet.