Flow Builder en producción: sesiones, versiones, informes y conexiones de base de datos

Conversa Labs

Conversa Labs

Última actualización el Aug 12, 2026

Visión general

Montar el flujo en el lienzo es solo el comienzo. Luego viene la operación: poner el flujo en producción, mantener un historial de versiones para revertir con seguridad, monitorear las sesiones (cada ejecución del flujo en una conversación), leer informes de rendimiento, organizar los flujos en carpetas y conectar datos externos al nodo SQL. La pestaña Disparos completa la operación: ejecuta un flujo publicado contra una audiencia entera (disparo masivo) con cadencia anti-bloqueo — consulta el artículo dedicado en Ver también.

Este artículo cubre el ciclo de vida de un flujo en Conversa Labs después de que ha sido diseñado. Para aprender a montar el flujo en sí, consulta el artículo de Flow Builder en Ver también.

Requisitos previos

  • El módulo Flow Builder habilitado para tu cuenta.
  • Administrador para publicar/despublicar, versionar, gestionar carpetas y gestionar conexiones de base de datos. Los agentes pueden listar y monitorear sesiones, abrir informes y usar conexiones ya creadas.
  • Para el nodo SQL (sql_query): una conexión de base de datos externa configurada y probada.
  • Para que los informes y el monitoreo tengan sentido: al menos un flujo publicado y en uso.

Paso a paso

  1. Publica el flujo cuando esté listo. A partir de ahí sus disparadores pueden iniciarlo.
  2. Monitorea las sesiones en la lista de ejecuciones: filtra por flujo, conversación o estado.
  3. Abre los informes para ver volumen, finalizaciones y fallos en un periodo.
  4. Cuando necesites un cambio, edita el borrador y publica de nuevo — la versión anterior queda en el historial para que puedas revertir si hace falta.
  5. Organiza los flujos en carpetas por equipo o finalidad.
  6. Si un flujo consulta datos, crea y prueba la conexión de base de datos antes de usar el nodo SQL.

Configuración y opciones

Publicación y versiones

  • Publicar / Despublicar: publicar deja el flujo activo para sus disparadores; despublicar lo retira de producción sin eliminarlo.
  • Borrador: la copia de edición. Guardar el borrador valida la definición y nunca toca la versión publicada — puedes editar con libertad sin afectar a los flujos que ya están corriendo.
  • Historial de versiones: cada publicación guarda una versión. Puedes abrir una versión antigua para revisar qué cambió.
  • Restaurar (revertir): trae una versión anterior de vuelta como la actual.
  • Duplicar: crea una copia del flujo para experimentar sin riesgo para el original.
  • Purgar (eliminar definitivamente): borra el flujo de forma permanente. Esta acción no se puede deshacer.

Monitoreo de sesiones

Una sesión es una ejecución del flujo dentro de una conversación. Desde la lista puedes:

Acción Qué hace
Listar / filtrar Ve las sesiones por flujo, conversación o estado (en ejecución, en espera, finalizada, fallida, cancelada), paginadas.
Cancelar Detiene una sesión activa (en ejecución o en espera) y libera la conversación.
Reejecutar (rerun) Corre el flujo desde el inicio como una sesión nueva (mismo flujo, conversación, contacto y variables). Ideal para una sesión que falló o fue cancelada.
Reanudar (resume) Fuerza a una sesión atascada en "en espera" a continuar desde el nodo actual, como si la espera se hubiera satisfecho.
Eliminar Borra la sesión y su rastro de pasos. Si estaba activa, la conversación se libera antes.
Acciones masivas Selecciona varias sesiones y cancelar (solo las activas) o eliminar de una vez.

Métricas y alertas del runtime v2

El endpoint protegido /monitoring/metrics publica métricas globales y por tenant para lag de trigger, cola, reanudación y vencimiento; latencia de steps, efectos y proveedores; reintentos, deduplicación, leases vencidos, efectos desconocidos, DLQ, locks, pools y batches. Solo existe cuando el operador configura OPERATIONS_METRICS_TOKEN. Las alertas se evalúan cada minuto y los umbrales se pueden ajustar con variables FLOW_BUILDER_ALERT_*; los episodios viven en un único hash Redis con TTL. No se publica ningún payload, secreto, contacto, conversación ni dato personal. El operador debe aplicar los índices aditivos de observabilidad antes de habilitar esta recolección a gran escala.

Informes

Los informes muestran las métricas de ejecución de tus flujos — volumen de sesiones, finalizaciones y fallos. Puedes filtrar por flujo y por periodo (fecha inicial y final) para comparar el rendimiento a lo largo del tiempo.

Organización en carpetas

Agrupa los flujos en carpetas por equipo, canal o finalidad. Eliminar una carpeta no elimina los flujos que contiene — simplemente vuelven a quedar sin carpeta.

Conexiones de base de datos (nodo SQL)

El nodo SQL consulta una base de datos externa usando una conexión que registras una vez:

  • Crear/editar una conexión: indica el adaptador (PostgreSQL, MySQL o SQL Server), host, puerto, base, usuario y contraseña. La contraseña es de solo escritura — se acepta al guardar pero nunca se devuelve a la pantalla. Al editar, deja la contraseña en blanco para mantener la actual.
  • Probar conexión: abre el pool y ejecuta un SELECT 1 para confirmar que las credenciales funcionan.
  • Probar consulta: ejecuta la query del nodo contra una muestra limitada y muestra las filas más el SQL compilado y los parámetros — ves exactamente "qué va a ejecutarse", con las {{ variables }} resueltas igual que en runtime.
  • Galería de plantillas SQL: fragmentos de solo lectura (búsqueda, listado, agregación y joins) ya en el dialecto del adaptador elegido, para rellenar el campo de la consulta sin empezar de cero.

El runtime v2 acepta una sola instrucción de lectura parametrizada por nodo. Las escrituras SQL no aparecen en la galería ni se pueden publicar hasta que exista una superficie exclusiva para admin con confirmación humana.

Credenciales de solo escritura para HTTP y webhooks

Cuando un administrador aprovisiona una credencial del cofre, selecciónala por nombre en el nodo. La definición del flujo guarda solo una referencia opaca:

  • Solicitud HTTP admite bearer token, API key, Basic Auth y OAuth2. OAuth2 puede usar un access token estático, client_credentials o refresh_token; el intercambio de tokens usa los mismos límites y protección SSRF que la solicitud principal.
  • Webhook de salida usa una credencial de firma independiente.
  • Los secretos no entran en la definición, exportación, historial ni trace. Rotar una credencial conserva la referencia del flujo e invalida el token OAuth2 en caché.

Importar / exportar

  • Exportar: descarga la definición de un flujo para guardarla o llevarla a otra cuenta.
  • Importar: crea un flujo a partir de una definición exportada.
  • Probar solicitud HTTP: dispara una solicitud aislada (sin correr el flujo completo) para revisar la URL, las cabeceras y la respuesta antes de usarla en un nodo.

Casos de uso

  • Cambiar un flujo en producción con seguridad: edita el borrador, publica y, si algo sale mal, restaura la versión anterior en segundos.
  • Recuperar ejecuciones con problemas: encuentra las sesiones fallidas con el filtro de estado y reejecútalas en masa.
  • Destrabar una atención detenida: una sesión "en espera" que nunca recibió su respuesta puede reanudarse manualmente.
  • Consultar pedidos dentro del flujo: configura una conexión de base de datos, valídala con "Probar consulta" y usa el nodo SQL para responder al cliente con datos reales.

Consejos, límites y buenas prácticas

  • Publica los cambios importantes en horarios de menor movimiento y conserva el historial para revertir.
  • Reejecutar crea una sesión nueva; puede bloquearse si el flujo ya no está publicado o si ya existe otra sesión activa para la misma conversación y flujo.
  • Las acciones masivas tienen un tope de elementos por llamada — para volúmenes grandes, repite por lotes.
  • Trata la contraseña de la base como un secreto: es de solo escritura y nunca se muestra de vuelta en la interfaz.
  • Ejecuta siempre Probar conexión y Probar consulta antes de publicar un flujo que usa el nodo SQL.

Solución de problemas

  • Sesión atascada en "en espera": usa Reanudar (resume) para forzar la continuación desde el nodo actual. Solo funciona para sesiones en ese estado.
  • La sesión falló o fue cancelada: usa Reejecutar (rerun) para correr el flujo desde el inicio como una sesión nueva. Si se bloquea, confirma que el flujo sigue publicado y que no hay otra sesión activa para la misma conversación.
  • La conexión de base de datos falló en la prueba: revisa adaptador, host, puerto, base, usuario y contraseña; verifica que el adaptador esté disponible en el servidor y que la red permita el acceso.
  • El flujo está publicado pero no se dispara: revisa el disparador y si el flujo está vinculado a la bandeja de entrada correcta; busca errores en las sesiones recientes y confirma que la versión publicada sea la esperada.

Ver también