Skip to main content
El producto aplica sinergia para mantener las automatizaciones válidas:
  1. Disparador → acción: si una acción está en ALLOWED_TRIGGERS_BY_ACTION, solo esos triggers pueden usarla.
  2. Acción → siguiente acción: si una acción está en ALLOWED_NEXT_ACTIONS, solo las acciones listadas pueden ir inmediatamente después en la secuencia ordenada (pasos o recorrido del grafo).
Si una acción no figura en esos mapas (o no hay entrada), el comportamiento por defecto es permisivo: cualquier trigger y casi cualquier siguiente acción.
Fuente de verdad: packages/shared/src/workflow-synergy.ts (ALLOWED_TRIGGERS_BY_ACTION, ALLOWED_NEXT_ACTIONS). La API y la UI usan la misma validación.

​
Regla 1 — Triggers permitidos por acción

Por defecto permisivo: send_webhook, send_push_notification, create_alert y cualquier acción no listada aceptan cualquier trigger. Nota: scheduled no está en la lista de set_entity_status, run_risk_matrix, run_enrichment, create_kyc_validation, etc. Diseñá automatizaciones programadas solo con acciones permitidas para scheduled.

​
Regla 2 — Siguiente acción inmediata

Solo se valida el par inmediato. En grafos, el motor ordena las acciones (p. ej. BFS desde el trigger) y valida los mismos pares. Por defecto permisivo: si una acción no está en la tabla, puede seguir cualquier acción.

​
Cadenas típicas (ejemplos)

  • Onboarding: run_enrichment → run_risk_matrix → set_entity_status → create_alert / create_kyc_validation.
  • Alerta: create_investigation → assign_to → change_status → send_webhook.
  • Pagos: request_transaction_approval → set_transaction_status → send_webhook.
Los errores al guardar suelen indicar trigger ↔ acción o acción → siguiente inválidos.
Mantenimiento: cambios de sinergia en código → primero workflow-synergy.ts, luego esta página.