Automation Workflows

Automation Workflows are Certivant's event-driven orchestration layer. A workflow is a graph of nodes — a single Trigger, then any mix of Condition, Action, Wait, Parallel, Loop, and End nodes — that runs in response to something happening around a verification: a form is submitted, a check finishes, a reviewer makes a decision, a schedule fires.

They are deliberately separate from the decision policy (Tool 1). A risk policy decides the verdict; a workflow fans out side effects around it — route to a department, email the applicant, request another document, call your webhook, schedule a live conference, generate a PDF report.

What's in this section

• Triggers — the complete reference for every event that can start a workflow: when each one fires, the data it carries, real example payloads, and how to scope and filter it.

How a workflow runs, end to end

Something happens          The platform emits      A workflow run is created
in the platform     ──▶    a trigger event    ──▶  for each matching active
(form submit, check               │                workflow, then executed
finishes, cron…)                  │                node-by-node.
                                  ▼
                    dispatchWorkflowEvent(input)
                    ├─ find active workflows whose trigger.event matches
                    ├─ narrow by subject + scope (form / applicant / document / check)
                    ├─ apply the optional DSL filter against the event context
                    └─ enqueue a KycWorkflowRun for each survivor

Dispatch is fire-and-forget: a workflow-dispatch failure never blocks or fails the originating action (the upload still succeeds, the verdict is still written). Each run keeps an append-only log, and the triggering event's context is stashed on the run's first log entry so Condition nodes and Action templates can read it.

Versions and A/B tests

Workflows and decision policies are versioned: editing creates a draft, publishing freezes it as an immutable version, and the previous active version of that name is archived. Every record points at the exact version that handled it:

• a workflow run stores workflowId and workflowVersion;
• a decided verification stores policyId and policyVersion, repeated in the policy block (id, name, version) of the decision webhook payloads and in the policy.evaluated audit event.

An A/B test routes a share of new verifications to a challenger version of the same named workflow or policy. The variant is a pure function of the experiment and the verification id — sha256("<experimentId>:<verificationId>") → bucket 0–9999, lowest percent × 100 buckets go to B — so retries and re-orchestrations never flip a verification between variants. The routing is recorded on the verification (kyc_ab_assignment), in the workflow run's dispatch entry, and — for policies — as abTest: { experimentId, variant } in the policy.evaluated audit event and the risk score's verdictMeta.

Tests are managed from the dashboard editors (Versions & A/B test); the challenger draft is frozen while a test runs and publishing it ends the test. Tests are session-authenticated dashboard features — there is no API-key endpoint for them.

Plan availability

Automation Workflows require the kyc.automation_workflows feature (Pro plan and above). On lower plans the editor is visible but activating a workflow returns 402 with an upgrade prompt.