Fluxos de automação

Os Fluxos de automação são a camada de orquestração orientada a eventos da Certivant. Um fluxo é um grafo de nós — um único Gatilho, seguido de qualquer combinação de nós de Condição, Ação, Espera, Paralelo, Laço e Fim — que é executado em resposta a algo que acontece em torno de uma verificação: um formulário é enviado, uma checagem termina, um revisor toma uma decisão, um agendamento é disparado.

Eles são deliberadamente separados da política de decisão (Ferramenta 1). Uma política de risco decide o veredito; um fluxo distribui efeitos colaterais em torno dele — encaminhar para um departamento, enviar um e-mail ao solicitante, pedir outro documento, chamar o seu webhook, agendar uma conferência ao vivo, gerar um relatório em PDF.

O que há nesta seção

• Gatilhos — a referência completa de todos os eventos que podem iniciar um fluxo: quando cada um é disparado, os dados que carrega, exemplos reais de payloads e como definir o escopo e filtrar cada um.

Como um fluxo é executado, do início ao fim

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

O disparo é fire-and-forget (sem espera pela resposta): uma falha no disparo de um fluxo nunca bloqueia nem faz falhar a ação original (o envio ainda é concluído, o veredito ainda é gravado). Cada execução mantém um log somente de acréscimo, e o context do evento disparador é armazenado na primeira entrada do log da execução, para que os nós de Condição e os modelos de Ação possam lê-lo.

Versões e testes A/B

Fluxos e políticas de decisão são versionados: editar cria um rascunho, publicar o congela como uma versão imutável, e a versão ativa anterior daquele nome é arquivada. Cada registro aponta para a versão exata que o processou:

• uma execução de fluxo armazena workflowId e workflowVersion;
• uma verificação decidida armazena policyId e policyVersion, repetidos no bloco policy (id, name, version) dos payloads de webhook de decisão e no evento de auditoria policy.evaluated.

Um teste A/B direciona uma parcela das novas verificações para uma versão desafiante do mesmo fluxo ou política com o mesmo nome. A variante é uma função pura do experimento e do id da verificação — sha256("<experimentId>:<verificationId>") → balde 0–9999, e os baldes mais baixos (percent × 100) vão para B — de modo que novas tentativas e reorquestrações nunca trocam uma verificação de variante. O roteamento é registrado na verificação (kyc_ab_assignment), na entrada de disparo da execução do fluxo e — no caso das políticas — como abTest: { experimentId, variant } no evento de auditoria policy.evaluated e no verdictMeta da pontuação de risco.

Os testes são gerenciados pelos editores do painel (Versões e teste A/B); o rascunho desafiante fica congelado enquanto um teste está em execução, e publicá-lo encerra o teste. Os testes são recursos do painel autenticados por sessão — não há endpoint com chave de API para eles.

Disponibilidade por plano

Os Fluxos de automação exigem o recurso kyc.automation_workflows (plano Pro e superiores). Em planos inferiores, o editor fica visível, mas ativar um fluxo retorna 402 com uma solicitação de upgrade.