Módulo 1: Triggers Avanzados

Combinar Múltiples Triggers en un Workflow

Siguiente →

Descripción de la cápsula

Hasta acá cada workflow tenía un solo trigger. Pero a veces el mismo procesamiento debería dispararse por eventos distintos: "procesar leads cada mañana automáticamente Y también cuando alguien manualmente lo pide Y también cuando llega un webhook urgente". En n8n, puedes poner múltiples triggers en el mismo workflow — cualquiera de ellos dispara la ejecución.

En esta cápsula vas a aprender los patrones para combinar triggers sin que el workflow se vuelva caótico, los 3 casos de uso principales (mismo procesamiento, diferenciar por trigger, fallback), cómo diferenciar dentro del workflow qué trigger lo disparó (importante para procesar distinto), y los límites de cuándo es mejor tener workflows separados.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

  • ✅ Agregar múltiples triggers a un solo workflow
  • ✅ Reconocer 3 patrones de uso para combinar triggers
  • ✅ Diferenciar dentro del workflow qué trigger lo disparó
  • ✅ Decidir entre múltiples triggers en 1 workflow vs N workflows separados
  • ✅ Evitar las trampas comunes de la combinación

El patrón básico: múltiples triggers convergen

[Manual Trigger] ──┐
[Schedule Trigger]─┼─→ [Set: normalizar] → [resto del workflow]
[Webhook Trigger]──┘

Los 3 triggers están conectados al mismo nodo siguiente (Set). Cuando cualquiera dispara, el workflow ejecuta desde ese punto.

Cómo hacerlo

  1. Crear el workflow
  2. Agregar primer trigger (ej. Schedule)
  3. Agregar segundo trigger desde el + del canvas (no del primer trigger)
  4. Conectar ambos al primer nodo de procesamiento
  5. Repetir para más triggers si necesitas

Importante: los triggers no se conectan entre sí — cada uno es un punto de entrada independiente.

Los 3 casos de uso

Caso 1: Mismo procesamiento, diferentes triggers

Cuándo: quieres ejecutar exactamente la misma lógica desde varias fuentes.

Ejemplo: workflow que "procesa los leads del Sheet":

  • Schedule: cada día a las 9am, automático
  • Manual: alguien del equipo lo dispara cuando agrega leads urgentes
  • Webhook: un cliente VIP envía leads críticos via API

Todos hacen lo mismo: leer Sheet, procesar, notificar.

Beneficio: un solo lugar para mantener la lógica. Cambias el procesamiento, los 3 disparadores se benefician.

Caso 2: Procesamiento distinto según trigger

Cuándo: la lógica mayoritariamente la misma pero algunos detalles cambian según cómo se disparó.

Ejemplo: mismo workflow de procesamiento, pero:

  • Si vino de Manual: procesa y notifica también al usuario que lo disparó
  • Si vino de Schedule: procesa y notifica al canal general
  • Si vino de Webhook urgente: procesa con prioridad alta y notifica con @here

Necesitas bifurcar según el trigger origen (más abajo).

Caso 3: Fallback / redundancia

Cuándo: quieres respaldo — si el trigger primario falla, el secundario lo cubre.

Ejemplo:

  • Webhook (Stripe): captura pagos en tiempo real
  • Schedule (cada hora): consulta API de Stripe para pagos del horario y procesa los que no se capturaron por webhook

Híbrido push + polling de respaldo (cápsula 06).

Diferenciar qué trigger disparó

Para casos 2 y 3, necesitas saber cuál de los triggers disparó la ejecución.

Método 1: Inspeccionar el origen

Cada trigger tiene su propio nodo. En el workflow, puedes verificar cuál tiene output:

// Code node o expression
$('Manual Trigger').isEmpty()   // true si NO disparó este
$('Schedule Trigger').isEmpty()
$('Webhook Trigger').isEmpty()

Solo uno va a tener output — el que disparó.

Método 2: Marcar el trigger con Set node

Más limpio: agregar un Set después de cada trigger que marca el origen:

[Manual Trigger] → [Set: source = "manual"] ──┐
[Schedule]       → [Set: source = "schedule"]─┼─→ [resto]
[Webhook]        → [Set: source = "webhook"] ─┘

Después en el workflow, usar {{ $json.source }} para bifurcar.

Método 3: Diferenciar por estructura del input

A veces los triggers producen estructuras tan diferentes que el input mismo te dice cuál fue:

  • Webhook: $json.body.email
  • Schedule: $json vacío o con timestamp
  • Manual: similar al Schedule

Pero es frágil — la estructura puede cambiar entre versiones de n8n. Mejor usar Método 2.

Patrón completo: ejemplo con bifurcación

[Manual Trigger] ─→ [Set: source="manual"]────┐
[Schedule]       ─→ [Set: source="schedule"]──┼─→ [Procesar común] ─→ [Switch: source]
[Webhook]        ─→ [Set: source="webhook"]───┘                          │
                                                                          ├─ "manual" → Notificar usuario
                                                                          ├─ "schedule" → Notificar canal general
                                                                          └─ "webhook" → Notificar urgente @here

Pasos:

  1. Cada trigger marca su origen con Set
  2. Convergen en el procesamiento común
  3. Al final, Switch sobre source bifurca a notificaciones distintas

Cuándo separar en workflows distintos

Combinar triggers no siempre es la mejor decisión. Separa en workflows distintos cuando:

1. La lógica diverge mucho

Si lo que hace el workflow después del trigger es muy diferente según el origen, es mejor tener workflows separados que un workflow con un Switch enorme al inicio.

2. Los triggers tienen rates muy distintos

  • Schedule: 1 vez al día
  • Webhook: 100 veces al día

Combinarlos significa que cada vez que llega webhook, el Schedule está "compitiendo" en el mismo workflow (no realmente, pero los logs/ejecuciones se mezclan). Mejor separados.

3. Necesitas distintos Error Workflows por tipo

Si Manual y Schedule deberían fallar a distintos Slack channels, separados es más claro.

4. Distinto retention / settings

Por ejemplo, "save on success: none" para uno y "save: all" para otro.

Ejemplo: cuándo combinar vs separar

Escenario A: lectura de Sheet (combinar)

  • Schedule diario + Manual on-demand + Webhook urgente
  • Todos leen el mismo Sheet, procesan igual, notifican al mismo canal
  • Combinar: sí. La diferencia es solo "quién dispara".

Escenario B: respuesta a eventos de Stripe (separar)

  • payment.succeeded: crear factura, notificar ventas
  • customer.subscription.deleted: cancelar acceso, notificar retention team
  • invoice.payment_failed: pausar acceso, notificar billing

Separar: cada uno tiene flow muy distinto. Mismo trigger (Stripe webhook) pero dispara workflows distintos según el event.type — esto se logra filtrando en el trigger o teniendo workflows con filtros específicos.

Trampas comunes

Trampa 1: Triggers conectados entre sí (no funciona)

Qué pasa: Intentas conectar Schedule después del Manual. n8n no permite — los triggers son puntos de inicio, no pasos intermedios.

Cómo evitar: Recordar que los triggers son paralelos, cada uno punto de entrada. Conectarlos al mismo siguiente nodo.

Trampa 2: Webhook se ejecuta también con Schedule

Qué pasa: Asumes que tener Webhook + Schedule significa "Schedule llama al webhook". No funciona así. Schedule es un trigger independiente que ejecuta el workflow directamente.

Cómo evitar: Entender que cada trigger es independiente. No se invocan entre sí.

Trampa 3: Output inesperado según trigger

Qué pasa: Tu workflow funciona perfecto cuando lo dispara Schedule (output limpio). Cuando lo dispara Webhook, falla porque el output del webhook es { body: {...}, headers: {...} } (no {...} directo).

Cómo evitar: Normalizar apenas después del trigger:

[Webhook]       → [Set: data = $json.body, source = "webhook"] ──┐
[Schedule]      → [Set: data = $json, source = "schedule"]────────┼─→ resto usa $json.data uniformemente

Trampa 4: Mismo nombre de campo distinto significado

Qué pasa: Webhook trae email en body.email. Schedule trae email en email directamente. Tu workflow usa {{ $json.email }} y a veces funciona, a veces no.

Cómo evitar: mismo Trampa 3 — normalizar al inicio para que el resto del workflow tenga estructura uniforme.

Trampa 5: Múltiples Schedule en el mismo workflow

Qué pasa: Pones 2 Schedule diferentes ("lunes 9am" y "viernes 5pm"). Funciona, pero dificulta entender qué corre cuándo.

Cómo evitar:

  • Si los procesamientos son iguales, OK pero documenta con Sticky Note
  • Si son distintos, separa en 2 workflows

Ejemplo práctico: workflow de leads con 3 triggers

Vamos a diseñar un workflow real combinando triggers.

Requirements

  • Schedule cada mañana 8am: procesa todos los leads del Sheet acumulados
  • Manual: alguien del equipo lo dispara cuando agregaron leads urgentes y no quieren esperar
  • Webhook: plataforma de eventos manda leads de eventos en vivo (tiempo real)

Diseño

[Manual]    → [Set: source="manual", filter=null]    ──┐
[Schedule]  → [Set: source="schedule", filter=null]  ──┤
[Webhook]   → [Set: source="webhook", filter="event"]──┘
                                                       │
                                                       ▼
                                              [Lee Sheet con filtro opcional]
                                                       │
                                                       ▼
                                                [Procesa leads]
                                                       │
                                                       ▼
                                              [Switch sobre source]
                                                       │
                                ┌─────────────────────┼─────────────────────┐
                                │                     │                     │
                          "manual"              "schedule"             "webhook"
                                │                     │                     │
                                ▼                     ▼                     ▼
                          Slack al user        Slack al canal       Slack URGENTE
                          (mencionar)          general              @here

Notas

  • Set inicial unifica la estructura: source y filter se llenan en todos los triggers
  • Procesamiento común en el medio
  • Switch final para notificación distinta
  • Maintainable: cambias el procesamiento en un solo lugar

Resumen y siguiente paso

  • Múltiples triggers en un workflow es posible y útil — cada uno es punto de entrada independiente
  • 3 casos: mismo procesamiento, distinto según trigger, fallback/respaldo
  • Diferenciar trigger con Set node marcando source (más limpio que inspeccionar el input)
  • Cuándo separar workflows: lógica diverge mucho, rates muy distintos, diff Error Workflows, distintos settings
  • Trampas: triggers conectados entre sí (no funciona), output inesperado según trigger, mismos nombres diff estructura
  • Normalizar al inicio con Set para estructura uniforme

Antes de avanzar deberías poder:

  • Combinar 2-3 triggers en un workflow
  • Decidir entre combinar vs separar según el caso
  • Normalizar inputs distintos en un formato común
  • Diferenciar trigger de origen con Set + Switch

Lo que sigue (cápsula 08):

Cierre del módulo: mini-proyecto comparativo. Vas a construir un workflow que acepta los 4 tipos principales de trigger (Manual, Schedule, Webhook, App-event de Gmail) y verás en práctica cómo cada uno se comporta, cuándo brillar y cuándo defraudar.

Recursos adicionales

  1. Workflow Design with Multiple Triggers - Patrones avanzados.
  2. n8n Sticky Notes Documentation - Para documentar workflows con triggers complejos.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorPolling vs Event-Based: Cuándo Cada UnoSiguiente →Mini-Proyecto: Comparativa Práctica de los 4 Triggers Principales