Skip to main content

Shared context (event.data)

All steps in one execution share a single context object. The engine merges:
  • Nested objects aligned with DB rows: entity, transaction, investigation, kyc, alert (and sometimes alerts[]).
  • Flat IDs for compatibility: entityId, investigationId, alertId, kycValidationId, etc.
  • Rule metadata when triggerType is rule_triggered: rule.id, rule.name, rule.score, etc.
  • Enrichment and risk: enrichment, riskMatrix, updated scores on entity and flat fields like newScore / riskScore.
  • Standby: when an execution pauses, executionId and callbackToken are available for continue/cancel links.
Later conditions see updates from earlier actions in the same run (graph or steps).

Refresh when resuming standby

When an execution resumes after standby, the engine merges the stored snapshot with an optional payload, runs refreshContextForResume (reloads entity, transaction, investigation, KYC from the database), and preserves important paths written by previous actions (scores, IDs, etc.). So if the user completed KYC at the provider while the flow was waiting, the next steps can see up-to-date KYC without a new automation run—it is still the same execution.

KYC: two patterns

PatternWhat happens
A — Same execution (standby)e.g. create_kyc_validation → wait → user clicks Continue via continueUrl. Resume refreshes context from DB.
B — New automation on outcomeWhen the system emits kyc_approved, kyc_rejected, or kyc_validation_finished, other automations with those triggers start a new execution.
You can combine both: a standby flow for sending the session link, and separate policies triggered on final KYC outcome.

When standby actually pauses

Standby requires:
  1. waitAfterStep (or graph equivalent) configured, and
  2. The run goes through runAutomationById so an automation_executions row exists (executionId, callbackToken).
Typical paths: POST /automations/:id/run (with manual_execution), rules invoking the automation, scheduler (scheduled), create entity flow, etc. Reactive-only paths (e.g. alert_created, investigation_*, many KYC events) use processEvent without a durable execution row: wait does not pause the flow—it runs to completion in one shot.

Continue, cancel, and template URLs

When executionId and callbackToken are present, notification templates can expose:
  • continueUrl — continue the execution (GET with token or POST with auth).
  • cancelUrl — cancel the waiting execution.
See the API reference: Continue execution, Cancel execution, Waiting executions, Execution context.

Scheduled runs

Scheduled automations receive a narrow entity context by default. A process restart can skip a window—treat as an operational limitation unless your deployment documents recovery.
Maintenance: Standby behavior is implemented in automation-engine and related routes; keep this page aligned when execution semantics change.