Multi-paso y retrasos
Un flujo de trabajo de una sola acción rara vez es interesante. El valor real está en secuenciar — enviar un mensaje de bienvenida ahora, esperar 3 días, comprobar si volvieron, enviar un seguimiento, esperar una semana, transferir a un pastor. Los flujos de trabajo multi-paso hacen exactamente eso.
Secuencial vs paralelo
La mayoría de los flujos de trabajo son secuenciales — acción 1, luego acción 2, luego acción 3. Los construyes conectando el manejador inferior de una acción al manejador superior de la siguiente.
Cuando necesitas ejecutar múltiples ramas a la vez (ej. enviar WhatsApp y actualizar un campo personalizado al mismo tiempo), usa un nodo split. Ambas ramas comienzan inmediatamente cuando se alcanza split.
TIP
Los splits eventualmente se reúnen a través del flujo normal — no hay un nodo explícito de "unión". Cada rama termina independientemente.
Retrasos
La acción wait_delay pausa la ejecución por una duración especificada. Patrones comunes:
| Patrón | Por qué |
|---|---|
wait_delay 1 hora después de bienvenida | Deja que el nuevo miembro se asiente antes del siguiente mensaje |
wait_delay 7 días para segundo punto de contacto | Ritmo de seguimiento a recién llegados |
wait_delay 30 días luego comprobar compromiso | Hito de discipulado |
Los retrasos se almacenan en la base de datos, no se mantienen en memoria — así que un retraso puede durar días o semanas sin consumir recursos. Cuando el retraso transcurre, la ejecución continúa desde donde quedó.
Wait-until
Para momentos específicos del calendario (ej. esperar hasta el próximo domingo a las 9 AM), usa wait_until con una expresión de fecha. Esto es consciente de zona horaria — usa la zona horaria de tu iglesia, no UTC.
Un uso común es la bienvenida llega el martes a las 10 AM independientemente de cuándo se registraron, para que los miembros que se registran el sábado no reciban un mensaje en medio del servicio dominical.
Wait-event
wait_event pausa hasta que otro evento se dispare para el mismo sujeto. Ej. un flujo de trabajo puede esperar el próximo evento attendance.marked para el miembro antes de continuar. Útil para "si vuelven dentro de 30 días, haz X; de lo contrario haz Y."
También admite un tiempo de espera — si el evento no se dispara dentro del período de espera, la ejecución toma una rama alternativa.
Ramificación condicional
La acción condition evalúa un booleano y enruta a verdadero / falso. Puedes encadenar muchas condiciones para construir flujos complejos.
Para ramificación multi-vía (más de dos resultados), usa split con condiciones en cada rama, o encadena condiciones en serie.
Bucles
for_each itera sobre una lista. La lista usualmente viene de una acción find_members_by_segment anterior en el flujo de trabajo.
Dentro del bucle, cada acción se ejecuta una vez por elemento. El elemento actual está disponible como {{loop.current}} y el índice como {{loop.index}}.
WARNING
Los bucles sobre segmentos muy grandes (miles de miembros) pueden tomar tiempo. Construye un pequeño wait_delay entre iteraciones para evitar la limitación de tasa de tus proveedores de mensajería.
Orden FIFO
Dentro de una sola ejecución, las acciones se ejecutan en orden del grafo. A través de ejecuciones, GCM las procesa en orden FIFO — primero disparada, primero ejecutada. No hay cola de prioridad.
Esto importa cuando un disparador de alto volumen como attendance.marked se dispara para cientos de miembros durante un servicio dominical: la ejecución del flujo de trabajo de cada miembro se encola, y se procesan en el orden en que se marcó la asistencia.
La división async-vs-sync
GCM separa las ejecuciones de flujos de trabajo en dos rutas de ejecución:
- Sincrónica — acciones que se completan en milisegundos (set variable, update member, condition). Estas se ejecutan inmediatamente cuando se alcanza la acción.
- Asincrónica — acciones que bloquean (wait_delay, wait_event, send_message) o llaman a servicios externos lentos. Estas se programan en una cola y se reanudan más tarde.
No tienes que pensar en esto — el constructor lo maneja por ti. Pero es por eso que una ejecución con tres pasos wait_delay puede quedarse semanas sin procesamiento activo.
Ejemplo trabajado: secuencia de bienvenida
Un flujo de trabajo típico para recién llegados:
- Disparador —
member.createddonde tipo de membresía es Visitante. - Wait 1 hora.
- Send message — bienvenida por WhatsApp.
- Wait 7 días.
- Condition — ¿el miembro ha asistido a alguna reunión desde el registro?
- Rama verdadera — envía un mensaje "qué bueno verte de vuelta".
- Rama falsa — envía un mensaje "invitación para unirte este domingo".
- Wait 30 días.
- Send notification — al pastor apropiado: "Es momento de hacer seguimiento personal con este recién llegado."
Toda la cosa toma unos 5 minutos para construir en el constructor visual. Ver Flujo de seguimiento a recién llegados para el recorrido completo.
Reanudabilidad
Si GCM se reinicia mientras una ejecución está a medio ejecutar, la ejecución se reanuda desde donde quedó — ninguna acción se repite, ninguna acción se omite. El estado se persiste en la base de datos en cada límite de paso.
Preguntas comunes
¿Puede un wait_delay durar para siempre? El máximo es 365 días. Para ciclos más largos, encadena múltiples flujos de trabajo.
¿Puedo editar un flujo de trabajo mientras hay ejecuciones en vuelo? Sí — las ejecuciones en vuelo continúan usando la versión con la que comenzaron. Las ejecuciones recién disparadas usan la nueva versión.
¿Puedo cancelar una ejecución atascada? Sí — abre la ejecución en la página de monitoreo y haz clic en cancelar. Las acciones restantes se omiten.
Próximos pasos
- Monitoreo de ejecuciones — depurar qué pasó.
- Flujo de seguimiento a recién llegados — receta multi-paso completa.
- Acciones — el catálogo completo.