Workflows que llaman a otros workflows: sub-rutinas y ramas en paralelo

Cuando tus automatizaciones crecen, empiezas a copiar y pegar los mismos tres o cuatro nodos en cada flujo: etiquetar, notificar al equipo, registrar en el CRM. Ese copy-paste es deuda tecnica. La solucion son los sub-workflows y la ejecucion en paralelo: extraes la logica comun a un workflow reutilizable y lo invocas desde cualquier otro, ademas de correr varias ramas a la vez para que el flujo no se sienta lento. Esta guia arma el patron paso a paso con nodos reales de Omnifox.

El trigger Manual: la puerta de un sub-workflow

Un workflow normal arranca por un evento (mensaje, etiqueta, deal). Pero si quieres que otro workflow lo llame, su trigger debe ser Manual (llamado por otro workflow). Ese trigger no escucha ningun evento externo: solo se dispara cuando un nodo Llamar otro workflow lo invoca. Piensa en el como una funcion a la que le pasas el contacto y la conversacion actuales.

Ejemplo: crea un sub-workflow llamado "Registrar lead" con trigger Manual y estos nodos: Anadir etiqueta (lead), Crear oportunidad (deal), Registrar actividad/nota. Ahora cualquier flujo puede ejecutar esa rutina completa con un solo nodo.

Llamar otro workflow desde el flujo principal

En tu workflow principal agregas el nodo Llamar otro workflow y eliges "Registrar lead". El flujo queda asi:

1. Trigger Mensaje recibido (solo primero).
2. Nodo Enviar mensaje de bienvenida.
3. Nodo Llamar otro workflow -> ejecuta "Registrar lead".
4. Nodo Transferir a un agente.

El orden: Mensaje recibido -> Enviar mensaje -> Llamar otro workflow -> Transferir a un agente. Si manana cambias como se registra un lead, editas un solo sub-workflow y todos los flujos que lo invocan se actualizan. Eso es reutilizar logica comun.

Ejecutar ramas en paralelo

Por defecto los nodos corren en secuencia: cada uno espera al anterior. Cuando tienes tareas independientes que no dependen entre si, el nodo Ejecutar en paralelo las lanza a la vez. Es ideal cuando una accion podria tardar (una Peticion HTTP a un ERP, por ejemplo) y no quieres bloquear al resto.

Ejemplo de un flujo de pedido pagado:

1. Trigger Webhook entrante con path_match order.paid.
2. Nodo Ejecutar en paralelo que abre tres ramas simultaneas:
   • Rama A: Enviar plantilla de WhatsApp de confirmacion al cliente.
   • Rama B: Peticion HTTP al sistema de facturacion.
   • Rama C: Publicar en el Team en el espacio de Operaciones.
3. Nodo Unir ramas que espera a que las tres terminen.
4. Nodo Crear tarea de seguimiento para post-venta.

El orden: Webhook entrante -> Ejecutar en paralelo (A / B / C) -> Unir ramas -> Crear tarea de seguimiento. El nodo Unir ramas es clave: sin el, no sabrias cuando todas las ramas terminaron para continuar con seguridad.

Manejar errores con Try/Catch

Las integraciones externas fallan: una API se cae, un token vence. El nodo Try/Catch envuelve los nodos riesgosos y te da una rama alternativa cuando algo revienta. En el ejemplo anterior, la Peticion HTTP de la rama B es la candidata perfecta:

• Try: Peticion HTTP al sistema de facturacion.
• Catch: Anadir nota interna ("Fallo la facturacion, revisar manual") + Notificar al equipo por email.

Asi, si la API no responde, el cliente igual recibe su confirmacion (rama A) y el equipo se entera del problema en vez de perderlo en silencio. Sin Try/Catch, un error en un nodo puede cortar todo el flujo.

Otros nodos de control que ayudan

• Saltar a otro nodo: reorganiza el flujo sin cablear conexiones largas; util para volver a un punto comun despues de varias ramas.
• Bucle/para cada: recorre una lista (por ejemplo varios items) repitiendo un bloque de nodos.
• Definir variable: guarda un valor al inicio y lo reutilizas en el sub-workflow y en las ramas.
• Buscar conversacion previa: antes de crear un deal, verifica si ya existe una conversacion para no duplicar.

Buenas practicas y errores comunes

• No pongas un trigger de evento a un sub-workflow: si quieres invocarlo, su trigger debe ser Manual. Un trigger Mensaje recibido no se puede llamar desde otro flujo.
• Cuidado con la recursion: un sub-workflow que se llama a si mismo puede entrar en bucle. Manten el arbol de llamadas poco profundo.
• Usa Unir ramas despues de Ejecutar en paralelo siempre que necesites que todo termine antes de seguir. Si no te importa el orden final, puedes dejar que las ramas terminen solas.
• Reserva Try/Catch para lo que de verdad puede fallar (HTTP, integraciones), no para toda la logica interna.

Por que vale la pena

Modularizar tus automatizaciones te deja mantenerlas como codigo limpio: un cambio en un solo lugar, ramas rapidas que corren juntas y errores que no tumban el flujo. En Omnifox creas un sub-workflow con trigger Manual, lo llamas con Llamar otro workflow y combinas Ejecutar en paralelo, Unir ramas y Try/Catch desde el mismo editor visual. Empieza extrayendo tu logica repetida a un sub-workflow y notaras la diferencia en el primer mantenimiento. Arma tus sub-workflows en Omnifox.