Synergy

The product enforces synergy so that automations stay valid:

1. Trigger → action: If an action appears in ALLOWED_TRIGGERS_BY_ACTION, only those triggers may use it.
2. Action → next action: If an action appears in ALLOWED_NEXT_ACTIONS, only the listed actions may come immediately after it in the ordered sequence (steps or graph traversal).

If an action is not in those maps (or the map entry is missing), the default is permissive: any trigger and almost any next action.

​

Rule 1 — Allowed Triggers per Action

Default permissive: send_webhook, send_push_notification, create_alert, and any action not listed above accept any trigger. Notable: scheduled is not in the allowed list for set_entity_status, run_risk_matrix, run_enrichment, create_kyc_validation, etc. Design scheduled automations that only use actions permitted for scheduled.

​

Rule 2 — Allowed Next Action (Immediate Successor)

Only the immediate pair is checked. For graphs, the engine orders actions (e.g. BFS from the trigger) and validates the same pairs. Default permissive: If an action is not in this table, any action may follow.

​

Typical Chains (Examples)

• Onboarding: run_enrichment → run_risk_matrix → set_entity_status → create_alert / create_kyc_validation.
• Alert triage: create_investigation → assign_to → change_status → send_webhook.
• Payments: request_transaction_approval → set_transaction_status → send_webhook.

Errors on save usually mean trigger ↔ action or action → next action failed validation.

---

Maintenance: When changing synergy in code, update workflow-synergy.ts first, then this page.