Referencia de nodos

Esta es la enciclopedia del canvas. Cada nodo tiene qué hace, cómo se configura, qué salidas ofrece, y cuándo conviene (o no) usarlo.

Si estás arrancando, no leas esto de corrido. Primero Conceptos de Runia Nexus y Tu primer canvas. Después volvés acá para buscar nodos puntuales cuando los necesites.

Triggers

Los triggers son los puntos de entrada del canvas. Un canvas no corre solo, algo lo dispara. Puede ser un mensaje del cliente, un webhook externo, un horario programado, una etiqueta que se le agregó al contacto, o un evento de una integración.

Un canvas puede tener varios triggers. Cada uno es un camino distinto de entrada.

Inicio

Tipo: session_start

Se dispara cada vez que llega un mensaje entrante nuevo al canal (WhatsApp, Instagram, Telegram). Es el trigger más usado y viene por defecto en todo canvas.

Configuración
Ninguna. Es un nodo de sistema fijo.

Qué provee

Datos del contacto (sender_id, canal)
El mensaje recibido (texto, imagen, audio, etc.)
ID de la sesión activa

Salidas
Una sola: conectala al primer nodo del flujo (típicamente un agente).

Usar cuando
Querés que el canvas responda a mensajes entrantes. Es el patrón estándar.

Ojo
Si el agente tiene punto de retomada activado (un nodo marcado como donde seguir cuando llega un mensaje nuevo en una sesión ya abierta), los mensajes siguientes no vuelven a pasar por Inicio, sino que reanudan en ese nodo.

Cierre de sesión

Tipo: session_close

Se dispara justo cuando una sesión termina. Una sesión se cierra cuando el canvas llama a un nodo "Cerrar sesión" o cuando el operador humano cierra la conversación desde el inbox.

Configuración
Ninguna. Nodo de sistema.

Qué provee

sender_id, canal, ID de sesión
Motivo del cierre

Usar cuando
Querés correr algo al final de la conversación. Ejemplos:

Extraer datos del historial y loggearlos a Google Sheets
Pedirle al cliente que califique la atención
Notificar al equipo si la conversación terminó sin resolver

Patrón típico
Cierre de sesión → Extraer de conversación → HTTP request (Google Sheets)

Timeout de sesión

Tipo: session_timeout

Se dispara cuando una sesión expira por inactividad (el cliente dejó de contestar y pasó el tiempo configurado). Por defecto son 20 minutos, pero se puede cambiar por canal.

Configuración
Ninguna. Nodo de sistema.

Qué provee

sender_id, canal, ID de sesión

Usar cuando
Querés hacer algo si el cliente se desconectó a mitad de una conversación. Ejemplos:

Mandarle un mensaje de seguimiento ("¿Seguís ahí?")
Marcar el lead como "frío" en el embudo
Guardar el estado de la conversación para retomarla después

Respuesta a plantilla

Tipo: template_reply

Se dispara cuando un cliente responde a una plantilla de WhatsApp que le mandaste. Te permite armar un flujo específico según a qué plantilla respondió.

Configuración

Plantilla: el nombre de la plantilla a la que aplica este trigger

Qué provee

Datos del contacto (sender_id)
El mensaje de respuesta
Nombre de la plantilla

Usar cuando
Mandás una plantilla de reactivación, bienvenida o cobranza, y querés un flujo distinto según a cuál respondió el cliente.

Ejemplo
Mandaste la plantilla "recordatorio_turno". Con este trigger, cuando el cliente confirme o pida reprogramar, el canvas sabe de qué plantilla viene y rutea al flujo correcto.

Webhook

Tipo: webhook

Se dispara cuando un servicio externo manda un POST a una URL única del canvas. Te permite que sistemas de afuera (tu ERP, un pago, un formulario) gatillen un flujo en Runia.

Configuración

Nombre del trigger
Código corto: aparece al final de la URL del webhook que copiás en el sistema externo
Secreto: para validar que el POST viene de quien decís
Integración asociada (opcional)

Qué provee

El cuerpo del mensaje que mandó el sistema externo (accesible como trigger_data)
No provee datos del contacto automáticamente: si necesitás mandar un mensaje después, tenés que extraer el contacto del cuerpo del mensaje y pasarlo manualmente al siguiente nodo.

Usar cuando

Un sistema externo tiene que avisarle al canvas de algo (pago recibido, orden creada, stock agotado)
Integrás un servicio que no tiene integración nativa en Runia

Patrón típico
Webhook → Leer los datos que mandó el sistema externo → Guardar variables → Enviar mensaje al cliente

Programado

Tipo: scheduled

Se dispara en horarios o intervalos fijos. No arranca por un mensaje del cliente, arranca por tiempo.

Configuración

Cuándo ejecutar: en horarios programados (todos los días a las 9, los lunes a las 10) o como un retraso desde algún disparo
Zona horaria

Qué provee

No provee sender_id automáticamente. Si el flujo tiene que mandar mensajes a contactos, hay que elegirlos desde adentro del flujo (con una consulta o una lista definida).

Usar cuando

Querés mandar recordatorios periódicos (ej: "mandar cupón los viernes")
Limpieza automática (ej: "a las 3 AM, marcar como frío todo lead que lleve más de 30 días sin responder")
Reportes programados

Tag agregado

Tipo: tag_added

Se dispara cuando se le agrega un tag específico a un contacto. El tag se puede agregar desde el inbox manualmente, desde otro canvas, o desde una integración.

Configuración

Tag: el nombre exacto del tag que dispara el flujo (ej: pago_confirmado)

Qué provee

Datos del contacto (sender_id)
El tag que se agregó

Usar cuando
Querés reaccionar automáticamente cuando un contacto entra en cierto estado:

Tag pago_confirmado al contacto, el canvas manda gracias + instrucciones
Tag vip, el canvas manda oferta exclusiva
Tag reclamo, el canvas transfiere a humano y avisa al equipo

Patrón típico
Un operador humano ve una conversación, la clasifica con un tag, y el canvas arranca automáticamente la siguiente acción. Ahorra trabajo repetitivo al equipo.

Manual

Tipo: manual

Se dispara cuando un operador humano le da play al canvas desde el inbox. No corre solo, requiere que alguien del equipo lo lance sobre una conversación.

Configuración
Ninguna.

Qué provee

Datos del contacto
Quién lo disparó (operador)

Usar cuando
Querés un flujo que el equipo lance puntualmente. Ejemplos:

"Mandar catálogo PDF + preguntar preferencias"
"Encuesta de satisfacción post-venta"
"Arrancar cobranza para este contacto"

Es básicamente una macro que el operador ejecuta con un click.

Evento de integración

Tipo: integration_event

Se dispara cuando una integración externa emite un evento. Por ejemplo: Calendly confirmó un turno, Stripe cobró un pago, Google Calendar reagendó una reunión.

A diferencia del webhook genérico, este trigger ya te entrega los datos normalizados según el tipo de evento, independientemente del proveedor.

Configuración

Fuente: código del proveedor (calendly, google_calendar, etc.)
Tipo de evento: booking_created, booking_canceled, booking_rescheduled, etc.
Integración específica (opcional): si la empresa tiene varias cuentas del mismo proveedor, filtrás a una sola.

Qué provee (según el tipo de evento)
Para reservas (booking_created, booking_rescheduled):

Nombre, email, teléfono del contacto
Horario de inicio y fin
Nombre del evento, ubicación
Links de reagendar y cancelar

Para cancelaciones (booking_canceled):

Nombre, email del contacto
Horario original
Motivo de cancelación (si lo dejó)

Usar cuando

Alguien reserva en Calendly y querés confirmarle por WhatsApp
Un turno se cancela y querés liberar el slot + avisar al equipo
Stripe confirma un pago y activás el flujo de onboarding

Patrón típico
Evento de integración (Calendly booking_created) → Enviar mensaje de confirmación → Cerrar sesión

Los tipos de evento disponibles dependen de qué integraciones tenés conectadas. Si no ves el evento que buscás, verificá en Configuración → Integraciones que la integración correspondiente esté activa.

Agentes IA

Los nodos de esta categoría usan un modelo de IA para procesar información. Son los más caros (tienen costo por uso) y los más potentes. Usalos cuando necesitás que entienda o razone sobre contenido, no para decisiones que se pueden resolver con reglas.

Agente

Tipo: agent

El cerebro del canvas. Un nodo conversacional con IA que recibe el mensaje del cliente más el historial, y genera una respuesta. Puede llamar "herramientas" (flow tools) para decidir qué camino tomar después.

Configuración

Prompt (5 secciones): identidad, responsabilidades, restricciones, tono, formato
Proveedor y modelo: OpenAI (gpt-4.1-mini, gpt-5-mini) o Anthropic (Claude Haiku 4.5)
Temperatura: cuánta creatividad tiene el agente. 0 = siempre responde igual ante el mismo input. 1 = respuestas más variadas
Flow tools: herramientas con las que el agente decide a qué parte del flujo ir (ejemplo: consultar_pedido, agendar_turno)
Punto de retomada: marca este nodo como el lugar donde seguir cuando llegue un mensaje nuevo en una sesión que ya tenía contexto
Memoria: qué hacer cuando el historial se hace largo. Dos opciones: cortar los mensajes viejos, o resumirlos en un solo bloque
Contexto adicional: datos del contacto (facts, tags, resumen de sesiones previas) que el agente ve al responder

Salidas

Siguiente: cuando el agente responde al cliente sin usar ninguna herramienta. Es el camino natural del flujo.
Una por cada flow tool: cuando el agente decide usar una herramienta específica (por ejemplo "el cliente quiere agendar turno"), la ejecución sale por la salida de esa herramienta.
Error: cuando la llamada al modelo falla (problema de red, modelo caído, etc.).

Usar cuando

Querés que el agente entienda el mensaje del cliente
Necesitás que decida entre varios caminos según lo que el cliente dijo
La conversación requiere mantener contexto

No usar cuando
Podés decidir con datos concretos (tags, canal, variables). Para eso usá Reglas duras. Son mucho más rápidas y no tienen costo.

Ojo con gpt-5-mini
Es un modelo que "piensa" antes de responder. La temperatura se fuerza a 1 (no la podés bajar) y tenés que elegir cuánto esfuerzo le dedica a pensar: bajo (rápido, por defecto), medio o alto. A más esfuerzo, mejores respuestas en casos complejos pero más demora y más costo.

Transcribir audio

Tipo: transcribe_audio

Convierte un audio de WhatsApp a texto usando el modelo Whisper de OpenAI. Útil para que un agente que viene después en el flujo pueda procesar mensajes de voz como si fueran texto.

Configuración

Modelo: Whisper (único disponible por ahora)
Idioma: opcional. Si no lo ponés, lo detecta automáticamente.
Ayuda extra: texto corto con contexto para guiar la transcripción (nombres propios, jerga del rubro)

Salidas

Éxito: provee la transcripción en {{node.<id>.transcription}} para usar en nodos siguientes.
Error: si la transcripción falla.

Patrón típico
Inicio → Switch por tipo de mensaje (audio) → Transcribir audio → Agente

Analizar imagen

Tipo: analyze_image

Manda una imagen a un modelo de visión y devuelve un análisis en texto. Útil para que un agente entienda qué hay en la foto que mandó el cliente.

Configuración

Modelo, prompt (qué querés que describa), nivel de creatividad (temperatura)
Formato de respuesta: texto libre o datos estructurados

Salidas

Éxito: provee el análisis en {{node.<id>.image_analysis}}.
Error: si falla.

Usar cuando
Querés que el agente "vea" lo que le manda el cliente. Para validar si la imagen cumple un criterio específico (ej: comprobante de pago), usá mejor Validador de imagen (más abajo), que tiene caminos separados para válida e inválida.

Analizar documento

Tipo: analyze_document

Lo mismo que Analizar imagen pero para archivos PDF u otros documentos. Extrae el contenido y lo pasa por un modelo para devolver un análisis.

Configuración

Modelo, prompt, nivel de creatividad, formato de respuesta

Salidas

Éxito: provee el análisis en {{node.<id>.document_analysis}}.
Error: si falla.

Extraer de conversación

Tipo: extract_from_conversation

Mira el historial de la conversación y extrae datos estructurados según los campos que le pidas. Muy útil para loggear información al cierre de la sesión (por ejemplo: qué producto consultó, qué presupuesto mencionó, qué dudas no pudo responder el bot).

Configuración

Modelo, nivel de creatividad, instrucciones generales
Campos a extraer: por cada campo, un nombre (key), un tipo (texto, número, booleano, lista de textos o lista de números), y una descripción clara.

Salidas

Listo: al menos un campo tiene valor útil.
Vacío: todos los campos vinieron vacíos (por ejemplo, el cliente no dijo nada de lo que se le preguntaba).
Error: falló el modelo.

Usar cuando

Al cerrar sesión, loggear datos a Google Sheets
Analizar preguntas que el bot no pudo responder
Extraer lead info: nombre, presupuesto, color del auto, etc.

Patrón típico
Cierre de sesión → Extraer de conversación → Listo → HTTP request (append a Google Sheets) / Vacío → (desconectado, se descarta)

Ojo con campos vagos
"Un campo" como descripción le da información pobre al modelo y extrae inconsistente. Mejor: "Color del auto que pidió el cliente, null si no mencionó".

Validador de imagen

Tipo: image_validator

Analiza una imagen y decide si cumple un criterio específico (ej: comprobante de pago con el monto y CBU correctos, DNI legible, foto de producto con daño claro). Incluye flujo de salida separado por válida e inválida.

Configuración

Fuente de la imagen: último mensaje o variable
Criterio de validación: descripción precisa de qué tiene que cumplir. Evitá vago ("tiene que estar ok"). Preferí: "Comprobante de transferencia a CBU 0000003100092... por al menos $10.000, fecha últimos 7 días."
Imágenes de referencia (hasta 5): ejemplos visuales que guían al modelo
Modelo: gpt-4.1-mini (rápido) o gpt-5-mini (piensa antes de responder, mejor para casos sutiles como leer dígitos borrosos)
Extracción opcional: si además de validar querés sacar campos estructurados (monto, fecha, número de DNI, etc.)

Salidas

Válida: provee el nivel de confianza, el motivo, y los campos extraídos si corresponde.
Inválida: provee el motivo del rechazo en castellano (por ejemplo: "la foto está muy borrosa").
Error: falló el análisis (sin imagen, credencial inválida, etc.).

Usar cuando

Validar comprobantes de transferencia antes de confirmar un pago
Verificar DNI / documentos de identidad
Chequear fotos de productos en un reclamo

Patrón típico

(cliente manda foto) → Validador de imagen (criterio: "comprobante a CBU X por $Y")
  → Válida: Agregar tag "pagado" → Enviar mensaje "¡Gracias, pago recibido!"
  → Inválida: Enviar mensaje "No es válido porque {{node.id.reason}}. Mandame otro."
  → Error: Enviar mensaje "Hubo un problema" → Transferir a humano

Lógica

Esta categoría es para decisiones y routing sin IA. Son nodos que evalúan datos concretos (tags, variables, canal), siempre responden igual ante los mismos datos, y no tienen costo. Usalos siempre que puedas antes de meter un agente.

Reglas duras

Tipo: hard_rules

Evalúa condiciones sobre datos concretos del contacto (tags, facts, variables, canal) y rutea según cuál se cumple. Las reglas se evalúan en orden: la primera que matchea gana.

Configuración

Lista de reglas. Cada regla tiene:
- Nombre visible
- Lógica: "se cumplen todas las condiciones" (Y) o "se cumple al menos una" (O)
- Condiciones: un campo a evaluar, un operador, y un valor esperado

Campos disponibles

Tags del contacto
Facts guardados del contacto
Variables de sesión
Canal del mensaje (WhatsApp, Telegram, Instagram)
Tipo de mensaje (texto, imagen, audio, video, documento)

Operadores disponibles

Comparación: igual a, distinto de
Texto: contiene, no contiene
Lista: está en la lista, no está en la lista
Números: mayor que, menor que, mayor o igual, menor o igual
Existencia: existe, no existe
Patrón: coincide con una expresión regular (para usuarios avanzados)

Salidas

Una por regla que definiste
Default: se usa cuando ninguna regla coincidió.

Usar cuando

"Si el contacto tiene tag VIP, mandalo por ruta VIP"
"Si viene de Instagram, usar un agente distinto"
"Si tiene email guardado, salteá el paso de pedirlo"

No usar cuando
La decisión requiere entender el contenido del mensaje ("si el cliente está enojado", "si quiere comprar"). Para eso, usá un agente con flow tools.

Resolver contacto

Tipo: resolve_contact

Busca un contacto existente o lo crea si no lo encuentra. Útil en triggers que no traen sender_id (webhooks, scheduled, integration_event).

Configuración

Datos para buscar al contacto: email, teléfono, o un identificador externo
Estrategia de búsqueda: cómo priorizar cuando hay coincidencias parciales
Crear si no existe: sí o no

Salidas

Encontrado: ya existía y lo trajo.
Creado: no existía y lo dio de alta.
No encontrado: no existía y no se pidió crearlo.

Patrón típico
Webhook → Resolver contacto (buscando por email que vino en el mensaje externo) → Creado → Enviar mensaje de bienvenida

Switch por canal

Tipo: channel_switch

Rutea según el canal del mensaje (WhatsApp, Instagram, Telegram).

Salidas

WhatsApp, Instagram, y una salida default para los canales que no matchearon.

Usar cuando
Querés un comportamiento distinto según el canal. Ejemplo: en WhatsApp mandar PDFs, en Instagram mandar links.

Switch por tipo de mensaje

Tipo: message_type_switch

Rutea según el tipo del mensaje entrante.

Salidas

Una por cada tipo: texto, imagen, audio, video, documento, interactivo (botones o listas), y una default para lo que no matcheó.

Patrón típico
Inicio → Switch por tipo → Audio → Transcribir audio → Agente / Imagen → Validador de imagen / Texto → Agente

Fork

Tipo: fork

Divide la ejecución en varias ramas paralelas. Cada rama corre al mismo tiempo, de forma independiente.

Configuración

Lista de ramas (mínimo 2, máximo 5): nombre de cada una.

Salidas
Una por cada rama.

Usar cuando
Querés hacer varias acciones a la vez sin que una bloquee a la otra. Ejemplos: avisar por Slack al equipo + loggear a Google Sheets + mandar confirmación al cliente.

Ojo

Las ramas comparten las variables de sesión. Si dos ramas escriben la misma variable al mismo tiempo, queda la última que escribió.
Máximo 2 niveles de ramas dentro de ramas.

Join

Tipo: join

Reagrupa las ramas de un Fork. Espera a que terminen y combina los resultados.

Configuración

Modo:
- Esperar todas: espera a que terminen todas las ramas. Si alguna falla, sale por Error.
- Esperar cualquiera: sigue con la primera que termine. Las otras siguen corriendo en paralelo pero el flujo no las espera.

Salidas

Completo: todas (o la primera, según el modo) terminaron bien.
Error: alguna rama falló (solo si elegiste "esperar todas").

Usar cuando
Después de un Fork, querés reagrupar antes de seguir. Si no te importa reagrupar (las lanzaste y seguís sin esperarlas), omitilo.

Variables

Tipo: set_variable

Define variables de sesión que podés usar más adelante en el flujo. Las variables persisten hasta que la sesión se cierra.

Configuración

Lista de variables. Por cada una: nombre, valor, y tipo (texto, número, booleano, lista, objeto). Si no especificás tipo, se guarda como texto.

Salidas

Siguiente: se pudo guardar.
Error: si el valor no se pudo convertir al tipo elegido (ej: querías guardar un número pero el valor era "abc").

Usar cuando

Guardar un contador (ej: "cuántas veces el cliente pidió hablar con humano")
Acumular datos entre nodos
Mantener estado dentro de la sesión

Referencia
Las variables se leen después con {{vars.nombre}}. Soporta acceso profundo: {{vars.pedido.status}}, {{vars.items.0.name}}.

Acciones

Esta categoría es lo que el canvas hace hacia afuera: enviar mensajes, guardar datos, llamar APIs, cerrar la sesión, etc.

Enviar mensaje

Tipo: send_message

Manda un mensaje al cliente. Es la acción más usada. Soporta texto, botones, listas interactivas, y opcionalmente esperar la respuesta del cliente.

Configuración

Destinatario (por defecto, quien mandó el mensaje entrante)
Mensaje: texto, texto con botones, o lista de opciones
Esperar respuesta: si lo activás, el flujo pausa hasta que el cliente conteste o expire el tiempo máximo.
Tiempo máximo de espera: ejemplo "30 minutos", "2 horas", "1 día".

Salidas (cambian según la configuración)

Sin esperar respuesta: una sola salida "Siguiente".
Esperando respuesta, sin botones: una salida "Respuesta" (cliente contestó) y otra "Timeout" (expiró el tiempo).
Con botones o lista: una salida por cada botón o item, más "Texto libre" (cliente escribió algo que no matchea ninguna opción) y "Timeout".

Usar cuando

Responder al cliente con info
Pedir datos con botones o lista de opciones
Pausar el flujo esperando confirmación del cliente

Ojo

Los mensajes enviados se agregan automáticamente al historial del agente. Los agentes que vengan después saben qué se mandó.
No pongas un "Inyectar mensaje" justo después de un "Enviar mensaje". Es redundante.
Cuando hay botones, la salida "Texto libre" significa "el cliente escribió algo que no matchea ningún botón", no "continuar sin esperar".

Enviar audio (voice message)

Tipo: voice_message

Genera un audio con voz clonada y lo envía como nota de voz de WhatsApp.

Configuración

Voz a usar: una de las que creaste en Configuración → Voces
Modo:
- Texto fijo: escribís el texto a decir (soporta variables como {{contact.name}})
- Texto generado por IA: le das instrucciones y un modelo genera el texto según el contexto de la conversación
Para el modo "texto generado": proveedor, modelo, creatividad, largo máximo

Salidas

Enviado: el audio se generó y se mandó.
Error: falló la generación o el envío.

Usar cuando

Querés agregar un toque más humano con la voz del dueño del negocio
Personalizar mensajes masivos con audio generado

Ojo

La voz tiene que existir. Si la borraste, el nodo falla.
Generar un audio puede tardar entre 30 y 90 segundos porque el servicio de voz a veces tarda en "calentarse" la primera vez. Tenelo en cuenta al diseñar el flujo.

Enviar plantilla

Tipo: send_template

Envía una plantilla de WhatsApp aprobada por Meta. Las plantillas son el único tipo de mensaje que se puede mandar a un cliente después de las 24 horas de su último mensaje.

Configuración

Plantilla: nombre e identificador
Idioma
Parámetros: los valores que completan los huecos de la plantilla ({{1}}, {{2}}, etc.)

Salidas

Éxito y Error

Usar cuando

Reactivar conversaciones viejas
Recordatorios programados
Bienvenidas fuera de ventana de 24h

Agregar / Quitar tag

Tipos: add_tag, remove_tag

Agregan o sacan un tag al contacto.

Configuración

Tag: nombre exacto

Usar cuando

Marcar estado del contacto: pagado, vip, lead_frio
Disparar otros canvases que reaccionan a tag_added

Guardar / Borrar fact

Tipos: save_fact, delete_fact

Guarda o elimina "facts" del contacto. Los facts son pares clave-valor persistentes (ej: nombre, email, ultima_compra).

Configuración

Para guardar: lista de pares nombre-valor (ej: email: [email protected])
Para borrar: lista de nombres de facts a eliminar

Usar cuando

Guardar datos del cliente para futuras conversaciones
Construir la memoria persistente del contacto

Diferencia con variables
Los facts sobreviven entre sesiones. Las variables solo duran durante la sesión actual.

Inyectar mensaje

Tipo: inject_message

Agrega una entrada invisible al historial de la conversación que ve el agente. El cliente NO la ve, solo los agentes que vienen después en el flujo.

Configuración

Rol del mensaje inyectado: usuario, asistente (como si lo dijera el bot), o respuesta de herramienta
Contenido: el texto a inyectar

Usar cuando

Pasarle contexto a un agente que de otra forma no tendría. Ejemplo: "[Sistema] Pedido #1234 en estado 'enviado'"
Cerrar una herramienta que el agente llamó antes de que siga conversando (rol "respuesta de herramienta")

Patrón típico con integraciones
Después de llamar una herramienta de integración (ej: consultar disponibilidad), el resultado se inyecta con rol "respuesta de herramienta" para que el agente pueda seguir con los datos reales.

Compactar historial

Tipo: compact_history

Resume el historial del agente y lo comprime. El inbox (el chat real que ve el cliente) no se toca, solo se modifica la "memoria" que el agente usa como contexto para razonar.

Configuración

Prompt y modelo para generar el resumen
Cuántos mensajes recientes mantener sin comprimir (los más viejos se resumen)

Usar cuando
La conversación se hizo larga y querés que el agente no pague el costo de todo el historial en cada turno.

Limpiar historial

Tipo: clear_history

Borra el historial del agente. El inbox (el chat real) no se toca.

Configuración

Cuántos mensajes recientes conservar. Si ponés 0, borra todo.

Usar cuando
Hay un cambio grande de tema o rama y querés "resetear" la memoria del agente sin cerrar la sesión.

HTTP request

Tipo: http_request

Hace una llamada HTTP a un servicio externo. Útil para integraciones que no tienen nodo dedicado.

Configuración

Método: GET (leer), POST (crear), PUT (actualizar), DELETE (borrar)
URL, cabeceras, cuerpo del mensaje
Tiempo máximo de espera
Variable donde guardar la respuesta

Salidas

Éxito: provee el cuerpo de la respuesta y el código de estado.
Error: provee el detalle del error.

Usar cuando

Consultar o mandar datos a tu sistema interno
Agregar una fila a Google Sheets
Integrar servicios sin nodo propio

Ojo
Siempre conectar out_error. Si la llamada falla y no hay salida de error, el flujo muere silencioso y el cliente queda colgado.

Delay

Tipo: delay

Espera un tiempo antes de seguir.

Configuración

Duración: ejemplo "5 minutos", "1 hora", "30 segundos"

Usar cuando
Querés simular tiempo de "pensamiento" del agente, o pausar antes de un recordatorio.

Esperar respuesta

Tipo: idle_timeout

Pausa silenciosa: no manda ningún mensaje, solo espera a que el cliente responda o expire el tiempo máximo. Útil para detectar que el cliente dejó la conversación colgada sin que el bot "hable por hablar".

Configuración

Tiempo máximo de espera: ejemplo "5 minutos", "1 hora", "30 segundos"

Salidas

Respuesta: el cliente contestó.
Timeout: pasó el tiempo sin respuesta.

Usar cuando
Querés mandar un mensaje de seguimiento si el cliente deja la conversación colgada:

Agente → Esperar respuesta (5 min) → Timeout: Enviar "¿Seguís ahí?"

Ojo
El estado de espera manda más que el punto de retomada del agente. Si hay una espera activa y el cliente manda un mensaje, la ejecución retoma en el nodo de espera, no en el punto de retomada del agente.

Esperar evento

Tipo: wait_for_event

Suspende la ejecución hasta que ocurre un evento externo. A diferencia de Esperar respuesta, este nodo NO se reanuda con mensajes del cliente: solo con el evento específico.

Configuración

Tipo de evento:
- Tag agregado: un tag específico se le agrega al contacto
- Webhook recibido: llega un webhook a la URL configurada
- Fact modificado: un fact del contacto cambia (opcionalmente, a un valor específico)
Tiempo máximo de espera (hasta 7 días)

Salidas

Evento: ocurrió lo que estabas esperando.
Timeout: pasó el tiempo sin que ocurra.

Usar cuando

Esperar un pago: "mandé el link, espero el tag pagado por hasta 2 días"
Esperar que confirme un sistema externo: "espero confirmación de mi sistema"
Esperar un cambio puntual: "espero que cambie el estado del pedido"

Patrón típico

Enviar plantilla (link de pago) → Esperar evento (tag agregado: "pagado", 2 días)
  → Evento: Enviar mensaje "¡Pago recibido!"
  → Timeout: Enviar mensaje "Tu pago no fue registrado"

Transferir a humano

Tipo: transfer_to_human

Pasa la conversación a un operador humano. La sesión cambia de dueño: del agente IA a un humano del equipo.

Configuración

Motivo: texto visible para el operador en el dashboard
Mensaje al cliente: qué se le dice antes de transferir
Asignación:
- Por rol: cualquier operador (le toca a uno distinto cada vez, rotando entre los disponibles), administrador, operador, o solo lectura
- Por email: derivar a una persona específica del equipo
Prioridad: baja, normal, alta, urgente
Marcar como "siempre humano": el contacto queda fijo con operador humano en futuras sesiones

Salidas

Mensaje pendiente: se dispara cada vez que el cliente manda un mensaje DESPUÉS de la transferencia y ANTES de que el operador tome la conversación. Sirve para que el bot "entretenga" o mande respuestas fijas mientras llega el humano.
Error.

Tres modos según cómo conectes la salida "Mensaje pendiente"

Silencio (por defecto): la dejás desconectada. Los mensajes caen en la bandeja del operador sin que el bot responda.
Mensaje fijo: la conectás a un "Enviar mensaje" con texto fijo ("ya te atendemos, aguantá").
Agente de contención: la conectás a un agente que mantiene al cliente enganchado mientras llega el humano.

Cerrar sesión

Tipo: close_session

Cierra la sesión explícitamente. Es un nodo terminal, no tiene salida hacia adelante (excepto la salida Error).

Configuración

Mensaje de cierre (opcional)
Guardar resumen: genera un resumen de la conversación y lo guarda como fact del contacto (útil como contexto en futuras sesiones).

Usar cuando

La consulta terminó bien y querés liberar la sesión antes del timeout.
El agente detectó que el cliente se despidió.

Ojo
Después de Cerrar sesión, el historial del agente se borra. El próximo mensaje del cliente arranca una conversación nueva.

CRM / Embudo

Esta categoría es para leer y escribir el embudo de ventas (pipeline) desde el canvas. Los operadores humanos ven los leads en Contactos → Embudo. Estos nodos permiten que el agente los cree y los mueva automáticamente según la conversación.

Antes de usar estos nodos, verificá en Contactos → Embudo que haya al menos un pipeline creado con sus etapas. Si no hay, los nodos fallan al ejecutarse.

Crear lead

Tipo: create_lead

Crea un lead (oportunidad de venta) en el pipeline. Queda visible para el equipo en el embudo.

Configuración

Título del lead (requerido, soporta variables)
Embudo (opcional, por defecto usa el principal de la empresa)
Etapa inicial (opcional, por defecto la primera)
Presupuesto, temperatura del lead (frío, tibio, caliente), nota rápida, campos personalizados
Próximo seguimiento (fecha)

Salidas

Éxito: provee el ID del lead creado, el contacto asociado y el título.
Error.

Usar cuando
El agente detectó un prospecto interesado y querés que aparezca en el embudo del equipo de ventas sin trabajo manual.

Patrón típico

Agente (con herramienta "registrar_interes") → Crear lead
  → Éxito: Inyectar mensaje (rol respuesta de herramienta) → Agente continúa
  → Error: Inyectar mensaje (rol respuesta de herramienta, "hubo un problema") → Agente continúa

Actualizar lead

Tipo: update_lead

Actualiza campos de un lead existente. Si no existe, lo crea (actualiza o da de alta en la misma operación).

Configuración

ID del lead a actualizar (típicamente {{vars.lead_id}})
Campos a modificar: temperatura (frío, tibio, caliente), presupuesto, nota rápida, campos personalizados, asignado a (email del operador)

Salidas

Éxito y Error

Usar cuando

Actualizar temperatura del lead según la conversación
Agregar notas automáticas
Reasignar a otro vendedor

Mover de etapa

Tipo: move_lead_stage

Mueve un lead a otra etapa del embudo. Si la etapa es terminal ("Ganado" o "Perdido"), el lead se cierra automáticamente.

Configuración

ID del lead
ID de la etapa destino (requerido)

Salidas

Éxito: provee el nombre de la etapa nueva, un indicador de si la etapa es terminal, y si es terminal, el tipo (ganado o perdido).
Error.

Usar cuando

El agente cierra una venta: mover a etapa "Ganado".
El cliente se desinteresó: mover a "Perdido".
El cliente aceptó la propuesta: mover a "Propuesta enviada".

Listar etapas

Tipo: list_stages

Devuelve las etapas disponibles del embudo. Útil para que el agente decida en el momento a qué etapa mover el lead, sin que las etapas estén fijadas en el canvas.

Configuración

Embudo específico (opcional, si tenés varios embudos y querés filtrar a uno solo)

Salidas

Éxito: provee la lista de embudos y etapas disponibles.
Error.

Usar cuando
No querés fijar los IDs de etapa en el canvas. El agente consulta las etapas disponibles y decide cuál corresponde según la conversación.

Integraciones

Los nodos de integración se generan automáticamente a partir de las integraciones que conectaste en Configuración → Integraciones. Si conectaste Calendly, aparecen 4 nodos de Calendly en el panel. Si conectaste Google Calendar con booking profiles, aparecen 5 nodos de Google Calendar.

Nodo de integración (genérico)

Tipo: integration_tool

Ejecuta una tool de una integración externa: consultar disponibilidad, agendar turno, cancelar, etc. Cada tool de cada integración conectada genera un nodo arrastrable separado.

Configuración

Proveedor y herramienta: se seleccionan al arrastrar el nodo
Parámetros: se pueden fijar (valor siempre igual) o dejar dinámicos (el agente decide el valor en cada ejecución según la conversación)
Mapeo de parámetros: referencias a variables o salidas de nodos anteriores

Salidas

Éxito: provee los campos que devuelve la herramienta (por ejemplo, los turnos disponibles).
Error: provee el motivo del error.

Patrón típico (disparado por un agente)

Agente (con herramienta "consultar_disponibilidad")
  → Nodo de integración (Calendly, consultar disponibilidad)
    → Éxito: Inyectar mensaje (rol respuesta de herramienta, con los turnos) → Agente sigue con datos reales
    → Error: Inyectar mensaje (rol respuesta de herramienta, "error X") → Agente pide disculpas

Ojo
Siempre conectar la salida Error. Credenciales expiradas, parámetros mal formados, límite de uso excedido, o el proveedor caído son fallas típicas que dejan al cliente colgado si no hay salida de error.

Google Calendar (5 nodos)

Cuando conectás Google Calendar y configurás perfiles de reserva (tipos de cita que se pueden reservar sobre un calendario), aparecen 5 nodos específicos. Están pensados para flujos tipo "pagá primero, después confirmo el turno" usando reservas temporales: se bloquea el horario sin crear el evento todavía, y se confirma después cuando llega el pago.

Consultar disponibilidad

Devuelve los turnos libres entre dos fechas según el perfil de reserva.

Configuración

Perfil de reserva (requerido)

El agente le pasa: fecha desde, fecha hasta (en formato año-mes-día).
Devuelve: lista de turnos disponibles con hora de inicio, hora de fin y etiquetas legibles.

Reservar temporal

Bloquea un turno por cierta cantidad de minutos SIN crear el evento real en Google Calendar. Diseñado para flujos tipo "pagá, después confirmo".

Configuración

Perfil de reserva (requerido)
Duración del bloqueo temporal, en minutos (por defecto 15)

El agente le pasa: hora de inicio del turno elegido.
Devuelve: identificador de la reserva temporal, hora de expiración y etiqueta legible.

Errores comunes

Turno ya tomado: otro cliente reservó el mismo turno justo ahora.

Confirmar reserva

Convierte una reserva temporal en un evento real de Google Calendar.

Configuración

Perfil de reserva (requerido)
Plantilla del título del evento: usa {{variable}} para incluir datos
Plantilla de la descripción del evento

El agente le pasa: identificador de la reserva temporal, email del invitado (opcional).
Devuelve: identificador del evento, link al evento, hora de inicio.

Errores comunes

Reserva temporal expirada: el cliente tardó más del tiempo permitido. Volver a consultar disponibilidad, reservar de nuevo, y reintentar.
Falló la inserción en Google: Google devolvió error. La reserva temporal se libera sola.

Liberar reserva temporal

Libera una reserva temporal antes de que expire (el cliente desistió).

El agente le pasa: identificador de la reserva temporal.
Devuelve: confirmación de que se liberó.

Cancelar reserva

Cancela un evento ya confirmado en Google Calendar.

Configuración

Perfil de reserva (requerido)

El agente le pasa: identificador del evento.
Devuelve: confirmación de que se canceló.

Flujo típico de reserva con pago

Agente (con herramientas: consultar_disponibilidad, reservar_temporal, confirmar)
  → Consultar disponibilidad → Inyectar turnos disponibles → Agente
  → Reservar temporal → Inyectar datos de la reserva → Enviar mensaje
    ("Turno reservado, pagá acá: {{link}}")
  → (esperar webhook de pago o confirmación del cliente)
  → Confirmar reserva → Inyectar datos del evento → Enviar mensaje
    ("¡Turno confirmado!")

Referencia de nodos

En esta página