Saltar al contenido principal

Nodo: Unión (Join)

El nodo Unión (Join) es responsable de sincronizar las ramas paralelas dentro de un workflow. Espera la convergencia de todas las ramas en curso antes de permitir que el flujo continúe al siguiente paso. Sin él, las ramas que corren en paralelo nunca se vuelven a encontrar, y el resto del proceso no puede continuar de forma controlada.

Piensa en el Join como una barrera de sincronización: ninguna rama pasa sola. El flujo solo avanza cuando el último camino paralelo también llega al nodo de unión.

Cuándo usar​

Usa el nodo Join siempre que tu workflow haya dividido el flujo en más de un camino simultáneo (fork) y necesites que todos esos caminos terminen antes de continuar.

Ejemplos prácticos de situaciones donde el Join es necesario:

  • Enviar un correo al solicitante y al mismo tiempo registrar los datos en una hoja de cálculo, y solo confirmar la finalización del proceso cuando ambas acciones terminen.
  • Disparar notificaciones para diferentes equipos en paralelo y, después de que todas sean enviadas, actualizar el estado de la instancia.
  • Solicitar aprobaciones de diferentes aprobadores en ramas separadas y esperar que lleguen todas las respuestas antes de tomar una decisión final.

Siempre que crees un fork en el canvas (es decir, conectes múltiples salidas de un nodo a nodos diferentes), necesitarás un Join para reunir esas ramas nuevamente en un solo flujo.

Entendiendo las Ramas Paralelas (Fork)​

Un fork ocurre cuando, desde un único nodo, se activan múltiples transiciones al mismo tiempo. Cada una de esas transiciones inicia una rama independiente, que ejecuta sus propios nodos sin esperar a las demás.

Las ramas son verdaderamente independientes: si una de ellas se bloquea en un nodo de aprobación esperando respuesta, las otras continúan ejecutándose normalmente a su lado.

Nodos que pueden crear un fork​

Cualquier nodo que tenga más de una salida conectada a nodos distintos puede crear un fork. Los casos más comunes son:

  • Aprobación: cada resultado configurado (por ejemplo, "Aprobado", "Rechazado", "Revisar") es una salida separada. Si conectas dos de esos resultados a nodos diferentes que luego necesitan reunirse, habrás creado un fork.
  • Si/Sino (If-Else): las salidas Verdadero y Falso también pueden crear ramas que necesitan converger.
  • Webhook de Salida: las salidas Éxito y Error pueden generar ramas paralelas.
  • Enviar Mensaje en Slack / Enviar Mensaje en Microsoft Teams: salidas de éxito y error.
  • Cualquier nodo en el que, manualmente en el canvas, arrastres múltiples conexiones desde la misma salida a nodos distintos que luego se unan.
Las ramas paralelas se ejecutan de forma independiente

Cada rama de un fork corre de forma autónoma. No comparten estado entre sí. El único punto de encuentro planificado es el nodo Join, que sabe cuántas ramas esperar y las espera a todas antes de continuar.

Configuración​

El nodo Join es intencionalmente simple: no tiene configuraciones funcionales más allá de la etiqueta (label), que sirve solo para identificación visual en el canvas.

El número de entradas que el Join esperará no se configura manualmente. El editor de workflows calcula ese número automáticamente en función de las conexiones dibujadas en el canvas. Cada flecha que llega al nodo Join representa una rama que deberá esperar.

Esto significa que:

  1. Conecta todos los caminos paralelos al nodo Join en el canvas.
  2. El sistema detecta automáticamente cuántas ramas llegan a él.
  3. No hay ningún campo numérico para completar.
El número de conexiones debe reflejar el fork real

El nodo Join espera exactamente el número de ramas que llegan a él en el canvas. Si creas un fork con tres caminos y conectas solo dos de ellos al Join, el tercero nunca llegará y el Join nunca avanzará. Asegúrate de que todas las ramas del fork estén conectadas al Join.

Comportamiento en Ejecución​

Durante la ejecución de una instancia del workflow, el nodo Join se comporta de la siguiente forma:

  1. La primera rama que llega al Join es recibida y el nodo entra en modo de espera.
  2. El estado de la instancia se actualiza para indicar que el flujo está esperando la convergencia de las ramas restantes.
  3. Conforme cada rama adicional llega, el Join registra su llegada.
  4. Cuando llega la última rama esperada, el Join libera el flujo y se ejecuta el siguiente nodo conectado a la salida del Join.

Qué ocurre si una rama falla​

Si cualquiera de las ramas paralelas encuentra un error no tratado durante su ejecución, el Join registra el fallo. El flujo no avanza y la instancia se marca con estado Falló. Esto garantiza que el proceso no continúe en un estado inconsistente, con datos parcialmente procesados.

Ejemplo de Flujo con Join​

A continuación, un ejemplo textual de cómo funciona un workflow con fork y Join en la práctica:

Escenario: Al recibir una nueva respuesta de formulario, el workflow debe enviar un correo de confirmación al solicitante y exportar los datos a una hoja de cálculo de Google Sheets al mismo tiempo. Solo después de que ambas acciones se completen, se debe actualizar el estado de la instancia.

[FORM_RESPONSE_TRIGGER]
        |
        v
    [Nodo A: Si/Sino (If-Else)]  ← verifica si el formulario está completo
        |
    (Verdadero)
        |
       FORK ──────────────────────────────────┐
        |                                     |
        v                                     v
[Rama 1: Enviar correo]          [Rama 2: Exportar a hoja de cálculo]
  Envía confirmación               (Google Sheets o Microsoft Excel)
        |                                     |
        └──────────────┬──────────────────────┘
                       v
                    [JOIN]
                       |
                       v
              [Definir Estado]
           Estado: "Procesamiento completado"

En este ejemplo:

  • El nodo Si/Sino (If-Else) evalúa si la respuesta está completa. En caso positivo, el flujo continúa hacia el fork.
  • Rama 1 ejecuta el envío del correo de confirmación.
  • Rama 2 ejecuta la exportación de datos a Google Sheets.
  • Las dos ramas corren en paralelo, de forma independiente.
  • El nodo Join espera que las dos ramas terminen.
  • Solo después del Join, el nodo Definir Estado se ejecuta y actualiza el estado de la instancia.

Buenas Prácticas​

  • Planifica el fork antes de agregar el Join. Identifica visualmente todos los caminos que parten del fork y asegúrate de que cada uno de ellos llegue al nodo Join.
  • Evita Joins "abiertos". Nunca dejes un Join con menos conexiones que el número real de ramas. El flujo quedará atascado indefinidamente esperando ramas que nunca llegarán.
  • Usa la etiqueta para documentar. Aunque sea simple, nombra el nodo Join con algo descriptivo como "Espera correo y hoja de cálculo" para facilitar la lectura del workflow por otros miembros del equipo.
  • Trata errores en las ramas. Si una rama puede fallar (por ejemplo, una llamada de webhook o integración con servicio externo), considera tratarla antes del Join para evitar que toda la instancia quede marcada como fallida.
El Join es obligatorio para re-sincronizar ramas paralelas

Sin el nodo Join, las ramas paralelas nunca convergen y el flujo no sabe cuándo puede continuar. Siempre que crees un fork en el canvas, agrega un Join al final de las ramas para garantizar que el proceso continúe de forma ordenada y predecible.