Automatisierungs-Workflows

Automatisierungs-Workflows sind die ereignisgesteuerte Orchestrierungsschicht von Certivant. Ein Workflow ist ein Graph aus Knoten — ein einzelner Auslöser, danach beliebige Kombinationen aus Bedingung-, Aktion-, Warten-, Parallel-, Schleife- und Ende-Knoten —, der als Reaktion auf ein Ereignis rund um eine Verifizierung läuft: ein Formular wird eingereicht, eine Prüfung ist abgeschlossen, ein Prüfer trifft eine Entscheidung, ein Zeitplan wird ausgelöst.

Sie sind bewusst von der Entscheidungsrichtlinie getrennt (Werkzeug 1). Eine Risikorichtlinie legt das Ergebnis fest; ein Workflow übernimmt die Nebenwirkungen rund darum herum — Weiterleitung an eine Abteilung, E-Mail an den Antragsteller, Anforderung eines weiteren Dokuments, Aufruf Ihres Webhooks, Planung einer Live-Konferenz, Erstellung eines PDF-Berichts.

Was in diesem Bereich enthalten ist

• Auslöser — die vollständige Referenz zu jedem Ereignis, das einen Workflow starten kann: wann es ausgelöst wird, welche Daten es enthält, echte Beispielnutzlasten sowie wie es eingegrenzt und gefiltert wird.

So läuft ein Workflow von Anfang bis Ende

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

Die Auslösung ist fire-and-forget: Ein Fehler bei der Auslösung eines Workflows blockiert oder verhindert nie die ursprüngliche Aktion (der Upload gelingt weiterhin, das Ergebnis wird trotzdem geschrieben). Jeder Lauf führt ein nur anfügbares log, und der Kontext des auslösenden Ereignisses wird im ersten Protokolleintrag des Laufs hinterlegt, damit Bedingungsknoten und Aktionsvorlagen darauf zugreifen können.

Versionen und A/B-Tests

Workflows und Entscheidungsrichtlinien sind versioniert: Eine Bearbeitung erzeugt einen Entwurf, die Veröffentlichung friert ihn als unveränderliche Version ein, und die bisher aktive Version dieses Namens wird archiviert. Jeder Datensatz verweist auf die genaue Version, die ihn bearbeitet hat:

• Ein Workflow-Lauf speichert workflowId und workflowVersion;
• eine entschiedene Verifizierung speichert policyId und policyVersion, wiederholt im Block policy (id, name, version) der Entscheidungs-Webhook-Nutzlasten und im Audit-Ereignis policy.evaluated.

Ein A/B-Test leitet einen Anteil neuer Verifizierungen an eine Herausforderer-Version desselben benannten Workflows oder derselben Richtlinie weiter. Die Variante ist eine reine Funktion aus dem Experiment und der Verifizierungs-ID — sha256("<experimentId>:<verificationId>") → Bucket 0–9999; die niedrigsten percent × 100 Buckets gehen an B —, sodass Wiederholungen und erneute Orchestrierungen eine Verifizierung nie zwischen Varianten wechseln lassen. Die Zuordnung wird an der Verifizierung (kyc_ab_assignment), im Auslöse-Eintrag des Workflow-Laufs und — bei Richtlinien — als abTest: { experimentId, variant } im Audit-Ereignis policy.evaluated sowie in verdictMeta des Risiko-Scores festgehalten.

Tests werden über die Editoren im Dashboard verwaltet (Versionen & A/B-Test); der Herausforderer-Entwurf ist während eines laufenden Tests eingefroren, und seine Veröffentlichung beendet den Test. Tests sind sitzungsgeschützte Dashboard-Funktionen — dafür gibt es keinen Endpunkt mit API-Schlüssel.

Verfügbarkeit im Tarif

Automatisierungs-Workflows setzen die Funktion kyc.automation_workflows voraus (Pro-Tarif und höher). In niedrigeren Tarifen ist der Editor sichtbar, aber das Aktivieren eines Workflows liefert 402 mit einem Hinweis zum Upgrade.