Flussi di lavoro automatizzati

I Flussi di lavoro automatizzati sono il livello di orchestrazione guidato da eventi di Certivant. Un workflow è un grafo di nodi — un unico Trigger, seguito da una combinazione di nodi Condizione, Azione, Attesa, Parallelo, Ciclo e Fine — che viene eseguito in risposta a un evento che accade attorno a una verifica: un modulo viene inviato, un controllo termina, un revisore prende una decisione, una pianificazione scatta.

Sono deliberatamente separati dalla politica decisionale (Strumento 1). Una politica di rischio decide il verdetto; un workflow distribuisce effetti collaterali attorno ad esso — instradare verso un reparto, inviare un'email al richiedente, richiedere un altro documento, chiamare il Suo webhook, pianificare una conferenza dal vivo, generare un report PDF.

Cosa contiene questa sezione

• Trigger — il riferimento completo di ogni evento che può avviare un workflow: quando si attiva, i dati che trasporta, esempi reali di payload e come limitarlo e filtrarlo.

Come funziona un workflow, dall'inizio alla fine

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

L'invio è fire-and-forget: un errore nell'invio di un workflow non blocca né fa fallire l'azione di origine (il caricamento va comunque a buon fine, il verdetto viene comunque scritto). Ogni esecuzione conserva un log in sola aggiunta, e il context dell'evento che ha generato l'esecuzione viene salvato nella prima voce del log, così che i nodi Condizione e i modelli delle Azioni possano leggerlo.

Versioni e test A/B

I workflow e le politiche decisionali sono versionati: modificare crea una bozza, pubblicare la congela come versione immutabile, e la precedente versione attiva con quel nome viene archiviata. Ogni record punta alla versione esatta che lo ha gestito:

• un'esecuzione di workflow memorizza workflowId e workflowVersion;
• una verifica decisa memorizza policyId e policyVersion, ripetuti nel blocco policy (id, name, version) dei payload dei webhook di decisione e nell'evento di audit policy.evaluated.

Un test A/B instrada una quota delle nuove verifiche verso una versione sfidante dello stesso workflow o della stessa politica con quel nome. La variante è una funzione pura dell'esperimento e dell'ID della verifica — sha256("<experimentId>:<verificationId>") → bucket da 0 a 9999, i bucket più bassi percent × 100 vanno in B — così che nuovi tentativi e riorchestrazioni non spostino mai una verifica da una variante all'altra. L'instradamento viene registrato sulla verifica (kyc_ab_assignment), nella voce di invio dell'esecuzione del workflow, e — per le politiche — come abTest: { experimentId, variant } nell'evento di audit policy.evaluated e nel verdictMeta del punteggio di rischio.

I test si gestiscono dagli editor della dashboard (Versioni e test A/B); la bozza sfidante resta congelata mentre un test è in corso, e pubblicarla termina il test. I test sono funzioni della dashboard autenticate con la sessione — non esiste un endpoint con chiave API per gestirli.

Disponibilità nel piano

I Flussi di lavoro automatizzati richiedono la funzione kyc.automation_workflows (piano Pro e superiori). Nei piani inferiori l'editor è visibile, ma attivare un workflow restituisce 402 con un invito all'upgrade.