Flujos de automatizaciónFlujos de trabajo de automatización

Flujos de trabajo de automatización

Flujos de trabajo ejecutables activados por eventos que dirigen, notifican y orquestan una verificación, sin establecer nunca el veredicto.

Los flujos de trabajo de automatización son la capa de orquestación basada en eventos de Certivant. Un flujo de trabajo es un grafo de nodos (un único Disparador seguido de cualquier combinación de nodos Condición, Acción, Espera, Paralelo, Bucle y Fin) que se ejecuta en respuesta a algo que ocurre alrededor de una verificación: se envía un formulario, termina una comprobación, un revisor toma una decisión o se activa una programación.

Están diseñados deliberadamente separados de la política de decisión (Herramienta 1). Una política de riesgo decide el veredicto; un flujo de trabajo distribuye efectos secundarios alrededor de él: derivar a un departamento, enviar un correo al solicitante, pedir otro documento, llamar a su webhook, programar una conferencia en vivo o generar un informe PDF.

Los flujos de trabajo nunca establecen el veredicto. El conjunto de acciones no tiene approve ni reject. El control más fuerte que tiene un flujo de trabajo sobre el resultado de una solicitud es escalate, que traslada la solicitud a revisión humana mediante la misma máquina de estados auditada y con bloqueo optimista que usa el panel. Aprobar o rechazar sigue siendo responsabilidad exclusiva de la política de decisión y de los revisores humanos.

Contenido de esta sección

  • Disparadores: la referencia completa de cada evento que puede iniciar un flujo de trabajo: cuándo se activa cada uno, los datos que transporta, ejemplos reales de carga útil y cómo limitarlo y filtrarlo.

Cómo se ejecuta un flujo de trabajo, de principio a fin

Ocurre algo                La plataforma emite         Se crea una ejecución del flujo
en la plataforma    ──▶    un evento de disparo  ──▶   para cada flujo activo que
(envío de formulario,             │                    coincida y luego se ejecuta
termina una comprobación,         │                    nodo por nodo.
programación…)                    ▼
                    dispatchWorkflowEvent(input)
                    ├─ buscar flujos activos cuyo trigger.event coincida
                    ├─ acotar por sujeto y alcance (formulario / solicitante / documento / comprobación)
                    ├─ aplicar el filtro DSL opcional sobre el contexto del evento
                    └─ encolar un KycWorkflowRun por cada flujo que sobreviva

El envío es sin espera de respuesta (fire-and-forget): un fallo en el envío del flujo de trabajo nunca bloquea ni hace fallar la acción original (la carga del documento se completa igualmente y el veredicto se sigue escribiendo). Cada ejecución mantiene un log de solo anexado, y el context del evento que la activó se guarda en la primera entrada del registro de la ejecución para que los nodos Condición y las plantillas de Acción puedan leerlo.

Versiones y pruebas A/B

Los flujos de trabajo y las políticas de decisión están versionados: al editar se crea un borrador, al publicar se congela como una versión inmutable y la versión activa anterior de ese nombre se archiva. Cada registro apunta a la versión exacta que lo gestionó:

  • una ejecución de flujo de trabajo guarda workflowId y workflowVersion;
  • una verificación decidida guarda policyId y policyVersion, que se repiten en el bloque policy (id, name, version) de las cargas útiles de los webhooks de decisión y en el evento de auditoría policy.evaluated.

Una prueba A/B dirige una parte de las verificaciones nuevas a una versión aspirante del mismo flujo de trabajo o política con el mismo nombre. La variante es una función pura del experimento y del identificador de la verificación: sha256("<experimentId>:<verificationId>") → cubo 0–9999; los cubos más bajos según percent × 100 van a B. Así, los reintentos y las reorquestaciones nunca cambian una verificación de variante. El enrutamiento se registra en la verificación (kyc_ab_assignment), en la entrada de despacho de la ejecución del flujo de trabajo y, en el caso de las políticas, como abTest: { experimentId, variant } en el evento de auditoría policy.evaluated y en el verdictMeta de la puntuación de riesgo.

Las pruebas se gestionan desde los editores del panel (Versiones y prueba A/B); el borrador aspirante queda congelado mientras una prueba está en curso, y publicarlo finaliza la prueba. Las pruebas son funciones del panel autenticadas por sesión: no existe un endpoint con clave de API para ellas.

Disponibilidad por plan

Los flujos de trabajo de automatización requieren la función kyc.automation_workflows (plan Pro y superiores). En los planes inferiores el editor está visible, pero activar un flujo de trabajo devuelve 402 con una invitación a mejorar el plan.