Skip to main content
Every automation has exactly one triggerType. When a matching event occurs (or a schedule fires, or the API runs the workflow), the engine starts an execution with event.data populated from that source.
Source of truth: trigger types are stored in the API (VALID_TRIGGER_TYPES in the automations schema). The UI lists the same values with labels and filters in the Workflow Builder.

​
Trigger Catalog

​
Who Emits Which Trigger?

  • Reactive events (alert, investigation, entity, transaction, KYC): the corresponding services emit the event to the automation engine (processEvent).
  • rule_triggered: synthetic event when a rule action runs the automation.
  • manual_execution: only when you call run with an automation whose trigger is manual.
  • scheduled: the automations scheduler process.
  • create_entity_flow: entity creation / onboarding path calling runAutomationById with the right workflow id.

​
Condition Contexts per Trigger

The product only shows condition fields that make sense for the trigger you picked. The UI maps each trigger to allowed contexts (transaction, investigation, alert, entity, KYC, rule): See also Context and standby for how event.data is shaped.

​
investigation_status_changed in detail

The event is emitted on every case status transition, regardless of where it came from: The event is not emitted when the status did not change. A call that resends the current status (for example CLOSED on an already closed case) updates the row but does not trigger automations, so it cannot produce duplicate notifications.

​
Statuses and previous status

The statuses produced by the flow are OPEN, IN_PROGRESS, PENDING_REVIEW and CLOSED (always uppercase). Besides the new status, the context exposes the previous status:
  • Condition: investigation.previousStatus (for example, notify only when it goes from IN_PROGRESS to PENDING_REVIEW).
  • Template: {{investigation.previousStatus}}.
On the first recorded transition of a case the previous status may be empty.

​
Chaining

If an automation changes the status with change_status or start_investigation, the event is emitted again so other automations can react. The automation that caused the change is not re-executed with that event, and chains stop after 3 hops.

​
Notes

  • Disabled or archived automations do not run.
  • KYC: kyc_approved / kyc_rejected / kyc_validation_finished may overlap in policy; design automations so you do not double-run the same business logic unless intended.
Maintenance: When the product adds a trigger, update this page and the synergy tables in Synergy.