Skip to main content
Cada automatización tiene exactamente un triggerType. Cuando ocurre un evento compatible (o salta un schedule, o llamás a la API), el motor inicia una ejecución con event.data cargado desde esa fuente.
Fuente de verdad: los tipos de trigger están en el esquema de automatizaciones (VALID_TRIGGER_TYPES). La UI lista los mismos valores con etiquetas y filtros en el Workflow Builder.

​
Catálogo de disparadores

​
Quién emite cada trigger

  • Eventos reactivos (alerta, investigación, entidad, transacción, KYC): los servicios correspondientes emiten el evento al motor (processEvent).
  • rule_triggered: evento sintético cuando una acción de regla ejecuta la automatización.
  • manual_execution: solo al llamar run con automatización cuyo trigger es manual.
  • scheduled: el proceso scheduler de automatizaciones.
  • create_entity_flow: flujo de alta / onboarding que llama runAutomationById con el workflowId correcto.

​
Contextos de condición por disparador

El producto solo muestra campos de condición coherentes con el trigger. Cada trigger se mapea a contextos permitidos (transacción, investigación, alerta, entidad, KYC, regla): Ver también Contexto y standby.

​
investigation_status_changed en detalle

El evento se emite en toda transición de estado del caso, sin importar desde dónde se haya originado: El evento no se emite si el estado no cambió. Una llamada que reenvía el estado actual (por ejemplo CLOSED sobre un caso ya cerrado) actualiza la fila pero no dispara automatizaciones, así que no genera notificaciones duplicadas.

​
Estados y estado anterior

Los estados que produce el flujo son OPEN, IN_PROGRESS, PENDING_REVIEW y CLOSED (siempre en mayúsculas). Además del estado nuevo, el contexto expone el estado anterior:
  • Condición: investigation.previousStatus (por ejemplo, avisar solo cuando pasa de IN_PROGRESS a PENDING_REVIEW).
  • Plantilla: {{investigation.previousStatus}}.
En la primera transición registrada de un caso el estado anterior puede venir vacío.

​
Encadenamiento

Si una automatización cambia el estado con change_status o start_investigation, el evento se vuelve a emitir para que otras automatizaciones reaccionen. La automatización que originó el cambio no se re-ejecuta con ese evento, y las cadenas se cortan a los 3 saltos.

​
Notas

  • Las automatizaciones deshabilitadas o archivadas no se ejecutan.
  • KYC: puede haber solapamiento entre kyc_approved / kyc_rejected / kyc_validation_finished; diseñá flujos para no duplicar lógica salvo que sea intencional.
Mantenimiento: al agregar un trigger en producto, actualizar esta página y las tablas de Sinergia.