Automatizar acciones con flujos de trabajo

Qué hace

Los Flujos de trabajo de automatización le permiten decir «cuando pase esto, haga aquello», sin código. Elige un evento que dispara el flujo (un solicitante envía un formulario, una verificación se aprueba, la puntuación de confianza cruza un umbral…) y después añade las acciones que se ejecutarán: enviar un correo al solicitante, asignar la verificación a un departamento y más.

Esta es la segunda de dos herramientas, y es importante distinguirlas:

Un flujo de trabajo nunca cambia el veredicto: eso es trabajo de la política. Los flujos orquestan alrededor de ella. Puede tener muchos flujos activos a la vez.

Antes de empezar

• Su plan debe incluir los Flujos de trabajo de automatización (Pro o superior). Si el elemento Flujos de trabajo de automatización del menú Desarrollador muestra la insignia «Requiere Pro», pida a su propietario que mejore el plan; consulte Facturación y créditos.
• Decida qué debe disparar el flujo y qué debe hacer.
• Para «asignar a un departamento», primero deben existir las cuentas de los miembros del equipo en su organización; consulte Invitar a compañeros de equipo.

Conceptos clave

• Disparador: el único evento que inicia un flujo. Cada flujo tiene exactamente uno.
• Filtro: una condición opcional sobre el disparador (misma sintaxis que las condiciones de las políticas, por ejemplo applicant.country IN ["CA","US"]). El flujo solo se ejecuta cuando el filtro es verdadero. Lee los datos del evento y los datos de la solicitud, los mismos campos que ve un nodo de Condición; por ejemplo, liveVerification.applicantAttended = false en un disparador de llamada finalizada.
• Acciones: los pasos ordenados que se ejecutan cuando se dispara el flujo.
• Nodos: además de las acciones, el lienzo tiene nodos de Condición (rama verdadera / falsa), Espera (pausa), Paralelo (divide en ramas), Bucle (repite un cuerpo acotado) y Fin (terminal); consulte Tipos de nodo más abajo.
• Ejecución: una ejecución de un flujo sobre un evento. Cada paso queda registrado para que vea exactamente qué ocurrió.

Cómo se ejecuta

flowchart LR
    A[An event fires<br/>e.g. form submitted] --> B{Matching active<br/>workflows?}
    B -->|trigger + filter match| C[Create a run]
    C --> D[Walk the actions:<br/>email · assign ·<br/>conditions · waits]
    D --> E[Run recorded<br/>with a full trace]
    B -->|no match| F[Nothing happens]

Los flujos se ejecutan automáticamente: no hay ningún botón de «ejecutar». Publicar un flujo lo activa; a partir de ese momento se dispara cada vez que ocurre su evento.

Pasos

Vincular un flujo a un formulario concreto

Para un flujo de form.submitted, vincúlelo a uno o varios formularios para que solo esos formularios lo disparen (de lo contrario, cada envío de formulario lo dispararía). Así es como los formularios de Apertura de cuenta e Hipoteca del banco ejecutan flujos distintos. La vinculación está en el disparador del flujo.

Tipos de nodo en el lienzo

Un flujo es un pequeño grafo. Arrastre nodos al lienzo y conecte sus puntos para definir el recorrido que sigue una ejecución. Además del único Disparador (añadido automáticamente) y de los nodos de Acción, dispone de:

Condiciones

Un nodo Condición bifurca en verdadero / falso según una expresión DSL: la misma gramática que una condición de política y que el filtro del disparador, de modo que hay un único motor de expresiones, no dos. Lee datos tipados sobre el evento: la puntuación de confianza (overallScore >= 75), la decision del evaluador, los campos del solicitante (applicant.country IN ["CA","US"]) y las señales de cada comprobación, como checks.liveness.confidence o sanctions.isMatch. Estos valores predefinidos tipados son los mismos campos que expone el diseñador de políticas, de modo que una expresión que funciona allí también funciona aquí. Una expresión que no se puede analizar falla de forma segura hacia la rama falsa: nunca coincide en silencio.

Los datos se cargan de nuevo desde la solicitud cada vez que se evalúa una condición, de modo que un flujo que estuvo en espera dos días ve el estado de hoy, no el del momento en que empezó. Además de las puntuaciones, puede probar:

CONTAINS comprueba si una lista contiene un valor (o si un texto contiene una palabra, sin distinguir mayúsculas); NOT CONTAINS es su opuesto. Un campo que la solicitud no tiene nunca coincide con !=, NOT IN o NOT CONTAINS; así, document.issuingCountry != "US" sigue siendo falso cuando no se leyó ningún documento, en lugar de pasar en silencio.

Esperas

Un nodo Espera detiene la ejecución y la reanuda más tarde. Cuatro modos:

• Durante una duración fija: se reanuda después de N minutos.
• Hasta que llegue un evento: se detiene hasta que se dispare un evento (por ejemplo, documento subido, estado cambiado, verificación de identidad en vivo iniciada / finalizada / completada, grabación lista) para la misma solicitud. Establezca un tiempo límite (horas o días; por defecto, 7 días): cuando transcurre, la ejecución toma la rama de tiempo límite del nodo o continúa por el camino normal si esa rama no está conectada.
• Hasta que se cumpla una condición: vuelve a comprobar un predicado DSL con una periodicidad fija y se reanuda cuando es verdadero (con un límite de seguridad para que un predicado que nunca se cumple no deje una ejecución detenida para siempre).
• Durante el horario laboral: se reanuda en el siguiente momento dentro de la ventana (por defecto, de lunes a viernes de 09:00 a 17:00 UTC; los días, las horas y la zona horaria son configurables, y los cambios de horario de verano se gestionan).

Paralelo

Un nodo Paralelo se divide en varias ramas que ejecutan cada una sus pasos y, después, continúa en una unión opcional cuando han terminado todas las ramas. Las ramas no se detienen: una Espera dentro de una rama pasa de largo, así que un bloque paralelo siempre termina.

Bucle

Un nodo Bucle repite un cuerpo mientras un predicado DSL sea verdadero, con un límite obligatorio de iteraciones: el bucle siempre termina, incluso si el predicado se mantiene verdadero (cuando se alcanza el límite, se indica en el rastro de ejecución). Un bucle sin expresión de condición ejecuta su cuerpo cero veces, de modo que un bucle mal configurado nunca puede girar sin control.

Resultados de los nodos Fin

Un nodo Fin es terminal: la ejecución se completa allí. Puede etiquetar un Fin con un resultado presentacional (aprobada, rechazada, escalada, completada o error) que se registra en la entrada final del rastro de la ejecución para indicar cómo terminó ese recorrido. Esta etiqueta es puramente descriptiva: describe la ejecución, NO cambia el veredicto de la verificación. El veredicto sigue en manos de la política de decisión; un Fin etiquetado como aprobada no aprueba nada.

Opciones y campos

Versiones, restauración y pruebas A/B

El botón Versiones y prueba A/B aparece en gris hasta que el flujo se ha guardado al menos una vez.

Un flujo es una cadena de versiones bajo un mismo nombre. Guardar siempre edita un borrador; Publicar lo congela como versión inmutable y archiva la versión activa anterior del mismo nombre. Cada ejecución registra la versión con la que se ejecutó (se muestra en la lista y en el rastro de ejecuciones).

Haga clic en Versiones y prueba A/B en la cabecera del editor para:

• Ver todas las versiones: borrador, activa, archivadas, y abrir cualquiera de ellas.
• Restaurar como nuevo borrador: copia una versión (por ejemplo, una anterior que quiera recuperar, o la activa que quiera modificar) en un nuevo borrador con el mismo nombre. Las versiones publicadas nunca se editan en su lugar.
• Ejecutar una prueba A/B: compare la versión activa (A) con un retador (B, un borrador o una versión anterior del mismo flujo). Elija qué porcentaje (0–100 %) de las verificaciones nuevas dispara el flujo en B en lugar de en A. El disparador, el alcance y el filtro de la versión activa siguen decidiendo si se ejecuta el flujo; la división solo decide qué versión se ejecuta. Una verificación siempre recibe la misma variante, y una ejecución termina en la versión con la que empezó.

Mientras la prueba está en curso, el borrador retador está congelado. La tabla de resultados muestra, por variante, las verificaciones asignadas, cuántas se aprobaron, rechazaron y escalaron, cuántas llegaron a una decisión, y cuántas ejecuciones del flujo se completaron o fallaron. Los flujos nunca fijan el veredicto, así que úselo para comparar resultados operativos (por ejemplo, un correo de recordatorio enviado antes). Publicar el retador termina la prueba; Detener prueba devuelve cada nueva verificación a la versión activa. Las ejecuciones sin verificación (programaciones, webhooks entrantes) siempre usan la versión activa.

Solución de problemas

Mi flujo no se ejecutó

Compruebe, en orden: que está publicado (activo, no borrador); que el evento de disparo realmente ocurrió; en un flujo de form.submitted, que el formulario que lo dispara coincide con la vinculación de formularios del disparador; y que cualquier filtro se haya evaluado como verdadero. Abra las ejecuciones del flujo para confirmar si se llegó a crear alguna.

El correo no llegó

Confirme que el destinatario se resolvió: en «el solicitante», el formulario debe haber recogido un correo electrónico; en «el propietario de la organización», su organización necesita un propietario con correo registrado. Revise la carpeta de spam y la configuración de envío de correo.

«Asignar a un departamento» no asignó a nadie

La acción necesita al menos un miembro seleccionado, y la verificación debe haberse creado (el flujo tiene que dispararse con un evento de verificación). Los miembros que elija deben pertenecer a su organización.

Publiqué una nueva versión: ¿qué pasa con las ejecuciones en curso?

Terminan con la versión con la que empezaron (por ejemplo, una ejecución detenida en una espera de dos días seguirá enviando su recordatorio). Los eventos nuevos ejecutan la nueva versión. Archivar un flujo es la única forma de detener sus ejecuciones en curso.

«Programar una verificación de identidad en vivo» se omitió

Abra el rastro de ejecución: el paso indica el motivo. Los motivos habituales son que la solicitud ya tiene una llamada programada o en curso (nunca se reserva una segunda), que el anfitrión elegido ha salido de su organización, o que su plan no incluye la verificación en vivo.

Un flujo se ejecutó más veces de lo que esperaba

Un flujo se ejecuta como máximo 10 veces por solicitud en 24 horas (a partir de ahí, el evento se omite y se registra como posible bucle), y los flujos que se activan entre sí mediante Activar otro flujo de trabajo se detienen tras 5 niveles. Si un evento se dispara repetidamente (por ejemplo, estado cambiado), añada un Filtro como status = "ESCALATED" para que el flujo reaccione solo al cambio que le interesa.

No veo «Flujos de trabajo de automatización» en el menú

Está en Desarrollador y es una función Pro. Si muestra la insignia «Requiere Pro», pida a su propietario que mejore el plan en Facturación y créditos.

Relacionado

• Diseñar una política de riesgo: la otra herramienta, la que decide el veredicto.
• Formularios: vincule un flujo form.submitted a un formulario.
• Webhooks: para enviar eventos de verificación a sus propios sistemas.
• Invitar a compañeros de equipo: añada a las personas a las que un flujo puede asignar trabajo.