## 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

- [Flow Builder: construir flujos conversacionales visualmente](/hc/ajuda/articles/automation-flows-flow-builder-es)
- [Reglas de automatización: disparadores, condiciones y acciones](/hc/ajuda/articles/automation-flows-regras-de-automacao-es)
- [Visión general de Automatización y Flujos](/hc/ajuda/articles/automation-flows-overview-es)
- [Disparos masivos en el Flow Builder](/hc/ajuda/articles/automation-flows-flow-builder-disparos-em-massa-es)