Módulo 1: Triggers Avanzados

Disparadores por eventos de apps (Gmail, Slack, Calendar)

Descripción de la cápsula

Los triggers de webhook genérico son potentes pero requieren setup: configurar URL, conectar el servicio externo, manejar auth. Los app-event triggers son la versión "lista para usar" — n8n ya sabe hablar con la app (Gmail, Slack, Calendar, Notion, etc.) y los configura por ti. Solo eliges qué evento te interesa y empiezas a reaccionar.

En esta cápsula vas a aprender los 3 app-event triggers más comunes (Gmail, Slack, Calendar), cómo se configuran, qué eventos soportan, y los detalles de implementación que diferencian un trigger útil de uno que falla en producción (limits, filtros, polling intervals).

Lo que vas a aprender

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

✅ Configurar Gmail Trigger para reaccionar a emails entrantes
✅ Configurar Slack Trigger para reaccionar a mensajes y eventos
✅ Configurar Google Calendar Trigger para eventos
✅ Usar filtros en los triggers para reducir ejecuciones innecesarias
✅ Entender push vs polling dentro de app triggers
✅ Reconocer limitaciones comunes y cómo trabajarlas

El patrón general de los app-event triggers

Todos los app-event triggers tienen la misma estructura conceptual:

Credential del servicio (ya configurada en G1-M05)
Evento que disparará el workflow
Filtros para restringir cuándo dispara (opcional pero recomendado)
Polling interval o "real-time" (depende del trigger)
Output con los datos del evento

Lo que varía entre apps son los eventos disponibles, filtros, y el modelo de detección.

Gmail Trigger

Configuración

Agregar nodo Gmail Trigger
Credential: tu credencial Google (G1-M05)
Event: Message Received (el más común — hay otros como Label Added)
Polling Interval: cada cuánto chequea Gmail (default 1 min en algunos planes, ajustable)

Filtros importantes

Gmail Trigger soporta filtros para no procesar cada email que llega:

Label IDs: solo emails con cierta etiqueta (ej: INBOX, etiqueta custom como cliente-importante)
Search (Gmail query): filtros tipo from:cliente@x.com subject:urgente

Sin filtros, cada email que llega dispara el workflow. Eso casi nunca es lo que quieres — la mayoría son irrelevantes.

Filtros con Gmail search syntax

Igual que en el buscador de Gmail:

Query	Qué hace
`from:cliente@acme.com`	Solo de ese remitente
`subject:urgente`	Subject contiene "urgente"
`has:attachment`	Solo con attachment
`is:unread label:soporte`	No leídos con label soporte
`from:@acme.com -from:bot@acme.com`	De acme.com excepto del bot

Casos de uso típicos

Auto-responder a emails con cierto subject
Crear ticket en sistema cuando llega email a soporte@
Notificar a Slack cuando email de cliente VIP llega
Procesar attachments (parsear PDF, guardar en Drive)

Limitaciones

Polling, no push: Gmail no tiene push notification público; n8n hace polling cada X minutos
Latencia: depende del polling interval (1-15 min típicamente)
Rate limits: Gmail API tiene quotas; polling muy frecuente puede saturar

Slack Trigger

Configuración

Agregar nodo Slack Trigger
Credential: tu credencial Slack (G1-M05)
Event: varios disponibles:
- Message Posted to Channel (alguien postea en un canal)
- App Mention (alguien menciona al bot)
- New User Joined (nuevo miembro al workspace)
- Reaction Added (alguien reacciona a un mensaje)
- ...y más

Detalles importantes

`Message Posted`: scope y configuración

Para escuchar mensajes en un canal, el bot debe estar invitado al canal (cápsula 5.04 de G1)
Por default, todos los mensajes del canal disparan el workflow — incluyendo del propio bot
Filtra mensajes del bot: activar opción Ignore Bots para no responder a tus propios mensajes

`App Mention`: el más útil

Solo dispara cuando alguien menciona explícitamente al bot: @n8n bot procesa este lead
Te permite construir un bot interactivo que solo actúa cuando le hablan
Menos ruido que escuchar todos los mensajes

Casos de uso típicos

Bot que responde a /comandos (ej: @bot resumen del dia)
Notificar a otro sistema cuando alguien escribe en #urgente
Trigger workflows desde Slack ("Mencionar al bot con 'procesar' procesa los leads del Sheet")
Crear ticket en sistema cuando alguien usa cierto emoji como reacción

Limitaciones

Solo eventos que el bot puede ver (canales donde está invitado, DMs si está habilitado)
Eventos privados (DMs entre humanos) no accesibles
Volume alto puede generar muchas ejecuciones (un canal activo = 100s de mensajes/día)

Google Calendar Trigger

Configuración

Agregar nodo Google Calendar Trigger
Credential: tu credencial Google
Event: varios disponibles:
- Event Created
- Event Updated
- Event Started (dispara cuando un evento empieza)
- Event Cancelled
Calendar: elige cuál calendario monitorear (puedes monitorear varios con triggers separados)
Polling Interval: similar a Gmail

Casos de uso típicos

Cuando se crea un evento, mandar email de confirmación al asistente
Cuando un evento empieza, mandar Slack recordatorio
Cuando un evento se cancela, liberar recursos (Zoom room, sala física)
Sync events a CRM o sistema interno

Limitaciones

Polling-based (no instantáneo)
Cambios muy rápidos pueden saltar a veces (evento creado y editado en <1 min puede capturarse como uno solo)

Polling interval: qué configurar

La mayoría de app-event triggers en n8n usan polling oculto. El intervalo afecta:

Latencia: menor intervalo = más responsive
Cost / rate limits: menor intervalo = más llamadas API

Recomendaciones por caso

Caso	Polling sugerido
Emails de soporte críticos	1-5 min
Emails marketing/newsletter	30-60 min
Slack mentions a bot interactivo	Push real-time (si Slack lo soporta)
Calendar para recordatorios	5-15 min
Sheet polling para procesar batch	15-60 min

Cómo configurar

En el trigger:

Polling Interval o Poll Times — algunos triggers usan minutos, otros cron expressions

Filtrar correctamente

El error más común con app-event triggers: filtrar después en el workflow en lugar de en el trigger.

Mal: filtrar después

[Gmail Trigger: cada email] → [IF: ¿subject contiene "urgente"?]
                              ├─ TRUE → procesar
                              └─ FALSE → terminar

Problema: cada email dispara el workflow, aunque inmediatamente se descarte. Estás gastando ejecuciones en items que ni siquiera te interesan.

Bien: filtrar en el trigger

[Gmail Trigger: filter "subject:urgente"] → procesar

Gmail Trigger configurado con subject:urgente solo dispara para esos emails. Ejecuciones se ahorran.

Trampas comunes

Trampa 1: No filtrar, gastando ejecuciones

(Lo de arriba.) Sin filtros, cualquier evento dispara el workflow.

Trampa 2: Trigger doble por edición rápida

Qué pasa: Configuras Calendar Trigger en Event Updated. Alguien crea y edita el evento en 30 segundos. Puede disparar 2 veces (creación + edición) o 1 vez (consolidado).

Cómo evitar:

Manejar idempotencia en el workflow (si llega 2x, no duplicar acciones)
O elegir Event Created si solo te interesa la creación inicial

Trampa 3: Bot escuchando sus propios mensajes

Qué pasa: Slack Trigger en Message Posted. El bot postea un mensaje. Eso dispara el trigger. El workflow vuelve a ejecutar. Loop infinito.

Cómo evitar:

Activar Ignore Bots en el trigger
O filtrar en el workflow con IF: {{ $json.user !== 'your-bot-id' }}

Trampa 4: Asumir push cuando es polling

Qué pasa: Configuras Gmail Trigger esperando que reaccione "instantáneamente" cuando llega email. Tarda 5 minutos. Te preocupas.

Cómo evitar: Saber que Gmail es polling (default ~1 min). Si necesitas <1min latencia, considera setup de webhook manual con servicios como Mailgun o SendGrid que sí mandan push.

Trampa 5: Volume inesperado

Qué pasa: Slack Trigger en Message Posted en un canal con 100 mensajes/día. Tu plan de n8n se queda sin ejecuciones a mitad de mes.

Cómo evitar:

Estimar volumen antes de activar
Usar App Mention o filtros en el trigger
Considerar resumen periódico en lugar de procesar cada mensaje

Cuándo NO usar app-event trigger

A pesar de ser cómodos, hay casos donde no aplica:

1. La app no tiene trigger nativo

Si la app que necesitas no aparece en n8n: usa Webhook genérico + configura el servicio externo manualmente.

2. Necesitas latencia <1 min y la app no lo soporta

Algunos servicios solo permiten polling (no push real). En estos casos:

Sube tu plan si hay opción de polling más frecuente
O configura webhook directo desde el servicio (si soporta)

3. El evento que necesitas no existe en el trigger

Ej: Gmail no tiene trigger "email leído" (eso es estado interno, no evento push). Alternativa: polling manual con filtro is:read.

Ejercicio: configurar Gmail Trigger para soporte

Objetivo: practicar con un caso real.

Tu tarea

Construye este workflow:

Gmail Trigger con filtro to:support@your-domain.com -from:your-own-email (Esto captura emails dirigidos a soporte, excluyendo los que tú mismo envías.)
Set node que extrae:
- sender_name: {{ $json.from.emailAddress.name || $json.from.emailAddress.address }}
- subject: {{ $json.subject }}
- snippet: {{ $json.snippet.substring(0, 200) }}

Slack node a tu canal de prueba:

📩 *Nuevo email a soporte*
De: {{ $json.sender_name }}
Subject: {{ $json.subject }}
_Preview:_ {{ $json.snippet }}...

Verificar

Mándate un email con asunto "Test soporte" a tu mismo (si tienes alias) o a support@your-domain real
Espera 1-5 min (polling interval)
Verifica que Slack recibe el mensaje

Lo que aprendiste

App-event triggers son plug-and-play vs webhook genérico
Filtros en el trigger son gratis y ahorran muchísimas ejecuciones
Polling interval afecta latencia

Resumen y siguiente paso

App-event triggers son nativos para apps específicas: Gmail, Slack, Calendar, Notion, etc.
Patrón común: credential + event + filters + polling interval
Filtros en el trigger ahorran ejecuciones — siempre filtrar antes que después
Polling interval equilibra latencia vs costo de API/ejecuciones
5 trampas: no filtrar, trigger doble, bot self-loop, asumir push, volume inesperado
Cuándo no usar app-event: app sin trigger nativo, latencia <1min imposible, evento no soportado

Antes de avanzar deberías poder:

Configurar Gmail Trigger con filtros
Configurar Slack Trigger evitando self-loops
Decidir polling interval según caso
Saber cuándo prefer app-event vs Webhook genérico

Lo que sigue (cápsula 06):

Ahora que conoces app-event triggers, queda la decisión meta: cuándo polling explícito y cuándo confiar en eventos. Vas a aprender los trade-offs: latencia, costo, complejidad, confiabilidad — y los 5 factores que guían la elección.

Recursos adicionales

Gmail Trigger Docs - Referencia.
Slack Trigger Docs - Referencia.
Gmail Search Operators - Para construir queries de filtro.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorWebhook Trigger Avanzado Siguiente →Polling vs Event-Based: Cuándo Cada Uno

Disparadores por eventos de apps (Gmail, Slack, Calendar)

Descripción de la cápsula

Lo que vas a aprender

El patrón general de los app-event triggers

Gmail Trigger

Configuración

Filtros importantes

Filtros con Gmail search syntax

Casos de uso típicos

Limitaciones

Slack Trigger

Configuración

Detalles importantes

Message Posted: scope y configuración

App Mention: el más útil

Casos de uso típicos

Limitaciones

Google Calendar Trigger

Configuración

Casos de uso típicos

Limitaciones

Polling interval: qué configurar

Recomendaciones por caso

Cómo configurar

Filtrar correctamente

Mal: filtrar después

Bien: filtrar en el trigger

Trampas comunes

Trampa 1: No filtrar, gastando ejecuciones

Trampa 2: Trigger doble por edición rápida

Trampa 3: Bot escuchando sus propios mensajes

Trampa 4: Asumir push cuando es polling

Trampa 5: Volume inesperado

Cuándo NO usar app-event trigger

1. La app no tiene trigger nativo

2. Necesitas latencia <1 min y la app no lo soporta

3. El evento que necesitas no existe en el trigger

Ejercicio: configurar Gmail Trigger para soporte

Tu tarea

Verificar

Lo que aprendiste

Resumen y siguiente paso

Recursos adicionales

`Message Posted`: scope y configuración

`App Mention`: el más útil