Los cronogramas cron y los webhooks cubren lo básico. Ejecute esta recipe cada mañana a las 8 AM. Active este workflow cuando un sistema de terceros envíe una solicitud POST. Eso maneja muchos casos de uso.
Pero la automatización real necesita reaccionar a las cosas que suceden — un workflow que se completa, un correo que llega, datos que cambian en una herramienta conectada, un elemento específico que aparece en una página web. Hacer polling con un temporizador esperando capturar el evento es un desperdicio y es lento. Esperar que alguien configure un webhook en el otro extremo asume que el otro extremo soporta webhooks.
JieGou ahora soporta cuatro tipos de disparadores basados en eventos que complementan las opciones existentes de cron y webhook. Cada uno vigila un tipo específico de evento y activa su recipe o workflow cuando ocurre.
El panorama completo de disparadores
JieGou soporta siete tipos de disparadores en dos categorías:
| Disparador | Modelo | Límite de velocidad | Caso de uso |
|---|---|---|---|
| Cron schedule | Temporizador | N/A | Ejecutar cada hora, diario a las 9 AM, etc. |
| Webhook | Push | 12/min por disparador | Sistema externo envía HTTP POST |
| Run completed | Push | 6/min por disparador, 30/min por cuenta | Encadenar recipes/workflows |
| Connector changed | Poll (60s–24h) | Según intervalo de poll | Reaccionar a cambios en CRM, hoja de cálculo o base de datos |
| Email received | Poll (300s por defecto) | 5 mensajes por ciclo | Correo entrante activa clasificación |
| Slack message | Push | Según Slack Events API | Mensaje en canal activa extracción |
| Browser event | Push | 20/min por usuario | Cambio en DOM activa investigación |
Los disparadores cron y webhook están disponibles en todos los planes. Los cuatro nuevos disparadores basados en eventos están disponibles en los planes Pro y superiores.
Encadenamiento por finalización de ejecución
Tipo: run_completed | Modelo: Push basado en bus de eventos en proceso
El patrón de automatización más común es “cuando X termina, iniciar Y”. Una recipe de resumen se completa, entonces un workflow de distribución debería iniciar. Un workflow de enriquecimiento de datos termina, entonces una recipe de puntuación debería ejecutarse contra los resultados.
El encadenamiento por finalización de ejecución maneja esto con cero polling. Usa un bus de eventos en proceso — cuando una ejecución termina, el evento se dispara inmediatamente, no en el siguiente ciclo de poll.
Opciones de configuración:
- Objetivo de vigilancia: Una recipe específica, un workflow específico, o “cualquier ejecución en esta cuenta”
- Filtro de estado: Activar solo en éxito, solo en error, o ambos
- Mapeo de output: Tres modos para extraer datos de la carga útil de la ejecución completada
Los tres modos de mapeo de output le dan control sobre qué datos fluyen a la ejecución activada:
- Passthrough — La carga útil completa del evento se convierte en la entrada. Útil cuando la recipe posterior espera el contexto completo.
- Mapeo de campos — Extraer campos específicos usando notación de ruta con puntos (por ejemplo,
event.output.summaryse mapea al campo de entradasummary). - Template — Usar sustitución
{{variable}}con soporte de rutas anidadas para transformaciones más complejas.
El límite de velocidad es 6 disparos por minuto por disparador — deliberadamente la mitad de la tasa de webhook de 12/min. Esto previene tormentas en cascada donde una cadena de disparadores se amplifica en cientos de ejecuciones concurrentes. El tope por cuenta de 30/min proporciona un respaldo adicional.
Ejemplo de pipeline: Una recipe de creación de contenido genera un borrador de blog. Al tener éxito, un workflow de distribución se activa que publica en canales sociales y programa envíos de correo. Al completarse la distribución, una recipe de reportes se activa que agrega métricas de engagement. Tres recipes, completamente automatizadas, sin cronograma cron adivinando cuándo termina cada etapa.
Detección de cambios en datos de conectores
Tipo: connector_changed | Modelo: Poll basado en Cloud Scheduler
No todo sistema envía webhooks cuando los datos cambian. Los registros de CRM se actualizan silenciosamente. Las celdas de hojas de cálculo cambian sin notificación. Las filas de base de datos se modifican por trabajos en segundo plano.
La detección de cambios de conectores sondea sus fuentes de datos conectadas a intervalos configurables (60 segundos a 24 horas) y se activa cuando los datos realmente cambian.
Cómo funciona la detección de cambios:
- Cada ciclo de poll obtiene los datos actuales del conector
- El sistema calcula un hash SHA-256 de la respuesta
- El hash se compara contra el hash almacenado previamente
- Si los hashes difieren, el disparador se activa
El primer poll después de la configuración almacena el hash sin activarse. Esto evita falsos positivos — no quiere que cada disparador se active en el momento en que lo configura solo porque “los datos son diferentes de nada”.
Filtros por tipo de cambio:
- Cualquier cambio — Cualquier diferencia en los datos hasheados
- Nuevos registros — Solo se activa cuando el conteo de registros aumenta
- Cambios en campos específicos — Monitorear campos particulares e ignorar cambios en otros
Mapeo de campos con transformaciones: Cuando el disparador se activa, puede mapear campos del conector a entradas de recipe con transformaciones integradas — string, number, boolean, json_parse y date_iso. Un campo de “valor del negocio” del CRM almacenado como cadena puede parsearse automáticamente como número antes de que llegue a su recipe de puntuación.
Ejemplo: Un conector de CRM monitorea el objeto “Leads”. Cuando aparece un nuevo lead o el estado de un lead existente cambia a “Calificado”, el disparador activa un workflow de puntuación de leads que enriquece el lead desde tres fuentes de datos y asigna una puntuación de prioridad.
Correo electrónico recibido
Tipo: email_received | Modelo: Poll basado en Gmail OAuth
El correo electrónico sigue siendo el punto de entrada para una cantidad sorprendente de procesos empresariales. Solicitudes de soporte, facturas de proveedores, notificaciones de alertas, respuestas de aprobación — todo llega a una bandeja de entrada.
El disparador de correo se integra con Gmail vía herramientas MCP OAuth y sondea en busca de nuevos mensajes que coincidan con sus criterios.
Configuración:
- Sintaxis de consulta de Gmail para filtrado — por ejemplo,
from:alerts@example.com subject:urgenteolabel:support-inbox is:unread - Intervalo de poll: 300 segundos por defecto, configurable
- Máximo de mensajes por ciclo: Hasta 5 (configurable) — previene que un backlog de 200 correos genere 200 ejecuciones concurrentes
- Rastreo de marca de agua vía
lastProcessedEmailId— el sistema recuerda el último correo que procesó, así que nunca reprocesa el mismo mensaje incluso si aún coincide con la consulta
Mapeo de correo a entrada extrae datos estructurados de cada correo:
| Campo del correo | Se mapea a |
|---|---|
subject | Campo de entrada de texto |
sender | Campo de entrada de texto |
body | Campo de entrada de texto o texto largo |
date | Campo de entrada de fecha |
headers | Campo de entrada JSON |
Ejemplo: Correos de soporte que coinciden con label:support-inbox is:unread activan un workflow de clasificación. El workflow clasifica el problema por categoría y urgencia, redacta una respuesta usando artículos relevantes de la KB, y enruta problemas de alta prioridad al equipo de guardia vía Slack.
Mensaje de Slack
Tipo: slack_message | Modelo: Push basado en Slack Events API
Algunos equipos ejecutan toda su operación desde Slack. Actualizaciones de estado, escalamientos de clientes, notificaciones de despliegue, solicitudes de decisión — todo sucede en canales.
El disparador de mensaje de Slack usa la Slack Events API para recibir mensajes en tiempo real. Sin polling, sin retraso.
Filtrado:
- Channel ID — Requerido. El disparador vigila un canal específico.
- Patrón de palabra clave o regex — Opcional. Solo mensajes que coincidan con el patrón activan el disparador.
- Filtrado automático de ruido — El disparador ignora mensajes de bots, ediciones de mensajes y mensajes del sistema. Filtra por
event.type === 'message'sinsubtype, así que solo obtiene mensajes genuinamente escritos por humanos.
Mapeo de Slack a entrada:
| Campo de Slack | Se mapea a |
|---|---|
text | Contenido del mensaje |
user | ID de usuario de Slack |
channel | ID del canal |
timestamp | Marca de tiempo del mensaje |
Ejemplo: Un canal #action-items recibe mensajes durante todo el día. Cada mensaje activa una recipe de extracción que identifica elementos de acción, asigna responsables basándose en @menciones, establece fechas límite a partir de lenguaje natural (“para el viernes”) y publica un resumen estructurado de vuelta en un canal #action-tracker.
Monitoreo de eventos del navegador
Tipo: browser_event | Modelo: Push basado en extensión del navegador
Este es diferente de los otros. En lugar de vigilar un servicio o bandeja de entrada, vigila lo que está sucediendo en el navegador mismo — el DOM de una página web.
La extensión del navegador monitorea páginas en busca de condiciones específicas y activa un disparador cuando ocurren. Se soportan cinco tipos de condición DOM:
| Condición | Qué vigila |
|---|---|
element_appears | Un selector CSS coincide con un elemento que no estaba ahí antes |
element_disappears | Un elemento previamente coincidente se elimina |
text_changes | El contenido de texto de un elemento coincidente cambia |
attribute_changes | Un atributo (class, data-*, etc.) de un elemento coincidente cambia |
url_changes | La URL de la página cambia (soporta patrones con comodines) |
Coincidencia de patrones de URL con soporte de comodines asegura que el disparador solo se active en páginas relevantes — https://monitoring.example.com/dashboard/* no se activará en pestañas no relacionadas.
Selección por selector CSS con extracción de datos: La configuración extractSelectors mapea campos de entrada a selectores CSS. Cuando el disparador se activa, la extensión lee los valores actuales de texto o atributo de esos selectores y los pasa como entrada estructurada.
Debounce: Los cambios DOM pueden ser ruidosos — una sola acción del usuario podría causar docenas de mutaciones. El debounce configurable (mínimo 1,000ms, 5,000ms por defecto) colapsa cambios rápidos en un solo evento de disparador. El límite de velocidad de 20 eventos de navegador por minuto por usuario proporciona una protección adicional.
Ejemplo: Un panel de monitoreo muestra un banner de alerta rojo cuando un servicio se degrada. El disparador vigila element_appears en .alert-banner.critical. Cuando se activa, extrae el texto de la alerta y el nombre del servicio afectado vía extractSelectors, luego activa un workflow de investigación que consulta logs, verifica despliegues recientes y redacta un resumen de incidente.
Arquitectura: handlers de fuente de eventos conectables
Los siete tipos de disparadores comparten la misma ruta de ejecución. La arquitectura usa un patrón de handler de fuente de eventos conectable:
- Cada tipo de fuente implementa la interfaz
EventSourceHandler - Un registro mapea cadenas de tipo de fuente (
run_completed,connector_changed, etc.) a instancias de handler - Los disparadores push (finalización de ejecución, Slack, navegador) entregan eventos directamente; los disparadores poll (conector, correo) se ejecutan en intervalos de Cloud Scheduler
- Ambas rutas convergen en
trigger-base.ts— la misma lógica de ejecución que procesa disparadores webhook procesa disparadores de eventos
Esta ruta compartida significa que los disparadores de eventos obtienen la misma deduplicación, resolución de entrada e historial de ejecución que los webhooks. Las claves de deduplicación previenen que el mismo evento active un disparador dos veces — crítico para fuentes push donde los reintentos de red podrían entregar eventos duplicados.
Observabilidad integrada vía tres métricas de Prometheus:
event_triggers_total— Contador por tipo de fuente y estadoevent_trigger_duration_seconds— Histograma de latencia de disparador a ejecuciónevent_polling_total— Contador para disparadores poll, rastreando ciclos con y sin cambios
Historial de ejecución
Cada disparador mantiene un historial de ejecución por disparador. La vista de historial muestra:
- Insignias de tipo de fuente codificadas por color — Distinguir rápidamente ejecuciones activadas por webhook de las activadas por correo o navegador
- Filas expandibles — Haga clic en cualquier entrada para ver la carga útil del evento sin procesar y la entrada resuelta que se pasó a la recipe o workflow
- Enlaces a ejecuciones resultantes — Salte directamente del evento del disparador a la ejecución de recipe o workflow que generó
Esto hace que la depuración sea directa. Si un disparador de cambio de conector se activó pero el workflow resultante produjo output inesperado, puede rastrear desde el evento del disparador hasta la entrada resuelta hasta la traza de ejecución en tres clics.
Disponibilidad
Los disparadores basados en eventos (finalización de ejecución, cambio de conector, correo recibido, mensaje de Slack y evento del navegador) están disponibles en los planes Pro y superiores. Los disparadores webhook y cron están disponibles en todos los planes. Vea todas las funcionalidades o inicie su prueba gratuita.