- Gatilho → ação: se uma ação está em
ALLOWED_TRIGGERS_BY_ACTION, apenas esses gatilhos podem usá-la. - Ação → próxima ação: se uma ação está em
ALLOWED_NEXT_ACTIONS, apenas as ações listadas podem vir imediatamente depois na sequência ordenada (passos ou percurso do grafo).
Fonte da verdade:
packages/shared/src/workflow-synergy.ts (ALLOWED_TRIGGERS_BY_ACTION, ALLOWED_NEXT_ACTIONS). A API e a UI usam a mesma validação.Regra 1 — Gatilhos permitidos por ação
| Ação | Gatilhos permitidos |
|---|---|
create_investigation | alert_created, rule_triggered |
generate_checklist, assign_to, add_note | alert_created, investigation_created, investigation_status_changed, investigation_updated |
start_investigation, change_status, change_priority, set_stage_role_access | investigation_created, investigation_status_changed, investigation_updated |
set_entity_status, run_risk_matrix | entity_created, create_entity_flow, alert_created, investigation_created, investigation_status_changed, investigation_updated, transaction_created, rule_triggered, kyc_approved, kyc_rejected, kyc_validation_finished, manual_execution |
run_basic_enrichment | manual_execution, entity_created, create_entity_flow |
run_enrichment, run_shareholders_flow | entity_created, create_entity_flow (run_shareholders_flow também permite manual_execution) |
create_kyc_validation | entity_created, create_entity_flow, alert_created, rule_triggered, kyc_approved, kyc_rejected, kyc_validation_finished, manual_execution |
request_transaction_approval, set_transaction_status | transaction_created, rule_triggered, manual_execution, scheduled |
send_webhook, send_push_notification, create_alert e qualquer ação não listada aceitam qualquer gatilho.
Nota: scheduled não está na lista de set_entity_status, run_risk_matrix, run_enrichment, create_kyc_validation, etc. Desenhe automações agendadas só com ações permitidas para scheduled.
Regra 2 — Próxima ação imediata
Apenas o par imediato é validado. Em grafos, o motor ordena as ações (ex.: BFS a partir do gatilho) e valida os mesmos pares.| Ação anterior | Pode ser seguida imediatamente por |
|---|---|
run_enrichment | run_risk_matrix, set_entity_status, create_alert, send_webhook, send_push_notification, create_kyc_validation |
run_basic_enrichment | run_shareholders_flow, run_risk_matrix, set_entity_status, create_alert, send_webhook, send_push_notification, create_kyc_validation |
run_shareholders_flow | run_risk_matrix, set_entity_status, create_alert, send_webhook, send_push_notification, create_kyc_validation |
run_risk_matrix | set_entity_status, create_alert, send_webhook, send_push_notification, create_kyc_validation |
set_entity_status | run_risk_matrix, create_alert, send_webhook, send_push_notification, create_kyc_validation |
create_alert | send_webhook, send_push_notification, create_investigation |
create_kyc_validation | set_entity_status, create_alert, send_webhook, send_push_notification, run_risk_matrix |
create_investigation | assign_to, add_note, change_status, change_priority, set_stage_role_access, send_webhook, send_push_notification, generate_checklist, start_investigation |
start_investigation, change_status, change_priority, assign_to, set_stage_role_access, add_note, generate_checklist | assign_to, add_note, change_status, change_priority, set_stage_role_access, send_webhook, send_push_notification, generate_checklist (igual para cada uma; start_investigation como próximo só a partir de create_investigation) |
request_transaction_approval | set_transaction_status, send_webhook, send_push_notification |
set_transaction_status | request_transaction_approval, send_webhook, send_push_notification |
Cadeias típicas (exemplos)
- Onboarding:
run_enrichment→run_risk_matrix→set_entity_status→create_alert/create_kyc_validation. - Alerta:
create_investigation→assign_to→change_status→send_webhook. - Pagamentos:
request_transaction_approval→set_transaction_status→send_webhook.
Manutenção: mudanças de sinergia no código → primeiro
workflow-synergy.ts, depois esta página.