Reglas de automatización: disparadores, condiciones y acciones

Visión general

Una regla de automatización ejecuta acciones automáticamente cuando ocurre un evento y se cumplen las condiciones que definiste. Es la forma más directa de eliminar el trabajo repetitivo: asignar conversaciones, añadir etiquetas, enviar mensajes, resolver conversaciones, mover negocios del CRM o notificar a sistemas externos mediante webhook.

Toda regla sigue la estructura disparador → condiciones → acciones:

• Disparador: el evento que inicia la evaluación (por ejemplo, "conversación creada").
• Condiciones: filtros que deben ser verdaderos para que la regla actúe.
• Acciones: lo que hace la plataforma cuando el disparador se activa y las condiciones se cumplen.

Requisitos previos

• Permiso de administrador para acceder al área de Automatización en Configuración.
• Al menos una bandeja de entrada con conversaciones, para que los disparadores tengan qué evaluar.
• Para acciones que dependen de otros módulos (CRM, Catálogo, Tareas, Follow-ups), el módulo correspondiente debe estar activo en la cuenta.

Paso a paso

Si aún no hay reglas, el estado vacío de la página resume el objetivo de la automatización y permite crear la primera regla sin buscar otra acción en la pantalla.

1. En Configuración, abre el área de Automatización y crea una nueva regla.
2. Dale a la regla un nombre y una descripción claros.
3. Elige cómo se ejecuta la regla. El selector ¿Cuándo debe ejecutarse esta regla? aparece cuando la ejecución diferida está habilitada en la cuenta:
   • Ejecutar al instante — "Se ejecuta en el momento en que ocurre un evento, siempre que se cumplan las condiciones." Es el comportamiento clásico, con el selector de disparador y la lista de condiciones justo debajo.
   • Ejecutar después de una espera — "Espera durante un periodo definido y se ejecuta solo si todo sigue igual. Si algo cambia, la regla se omite." En este modo, el disparador y las condiciones dan paso al bloque Condición de espera, detallado en Configuración y opciones.
4. Elige el disparador (evento). Los principales son:
   • Conversación creada, Conversación actualizada, Conversación resuelta, Conversación abierta;
   • Mensaje creado (entrante o saliente);
   • Contacto creado, Contacto actualizado, Contacto fusionado, Contacto eliminado — reglas que actúan directamente sobre la ficha del contacto, sin depender de una conversación;
   • Pedidos: pedido registrado, estado del pedido cambiado, pedido pagado, reembolso parcial ajustado, pedido reembolsado, pago revertido y negocio con pedidos totalmente pagados (con los módulos de Pagos/Comercio activos);
   • Pagos: cobro creado, confirmado, pagado, parcialmente reembolsado, vencido, reembolsado, fallido o cancelado. Confirmado significa que el cliente completó el pago aunque el gateway pueda liberar el saldo al vendedor más tarde; pagado/recibido registra esa etapa posterior del proveedor. No crees reglas duplicadas con las mismas acciones para ambos eventos;
   • Contratos: contrato visualizado, firmante firmó y contrato expirado (con el módulo de Contratos activo);
   • Agenda — dos niveles, y la diferencia importa:
     • Reserva creada / reprogramada / cancelada: el cliente reservó, reprogramó o canceló desde la página pública de reservas (es decir, hay una reserva detrás);
     • Evento de agenda creado / reprogramado / cancelado: la cita cambió en la agenda — incluso cuando un agente la edita, la arrastra o la cancela desde el panel, o desde la pestaña Agendar dentro de la conversación. Una cita con reserva dispara ambos niveles cuando la modificas desde el panel; una cita creada directamente en la agenda, sin reserva, dispara solo el nivel de evento.
   • eventos de CRM, Catálogo y Tareas cuando esos módulos están activos.
5. Añade condiciones. Combina campos (estado, prioridad, bandeja de entrada, etiquetas, idioma del navegador, atributos de contacto/conversación, campos del CRM) con operadores como igual a, distinto de, contiene o no contiene. Los disparadores de contacto y de pedidos exponen condiciones específicas: ciudad, tipo de contacto (visitante, lead o cliente), bloqueado, estado del pedido, gateway del pedido y monto del pedido — además de los atributos personalizados del contacto.
6. Define una o más acciones (consulta la lista abajo).
7. Guarda y activa la regla. Pruébala con una conversación real para confirmar el comportamiento.

Configuración y opciones

Acciones disponibles (varían según el disparador y los módulos activos):

Cuando los módulos están activos, aparecen acciones específicas: mover un negocio de etapa, asignar y definir valor/prioridad en el CRM, añadir un producto a un negocio en el Catálogo, crear tareas e inscribir al contacto en una secuencia de Follow-ups.

En los disparadores de contacto (creado/actualizado/fusionado) la regla corre sobre el contacto — y ahora ofrece todo el catálogo anclado al contacto: además de las acciones de contacto (etiquetas, nota, atributo), puedes crear un negocio en el CRM ya vinculado al contacto, mover etapa, crear una tarea o cita ligadas al contacto, enviar cobros y suscripciones, inscribir en follow-ups y contratos, acciones de engagement y de grupo de WhatsApp (el participante por defecto es el propio contacto), disparar un webhook y lanzar un flujo masivo. Las acciones que actúan sobre una conversación (asignar agente/equipo, resolver, enviar mensaje/nota/adjunto, SLA, IA/Maestro, plantilla de WhatsApp) siguen no disponibles en estos disparadores porque no hay conversación — usa Crear conversación para encadenar en un disparador de conversación.

• Condiciones "Y": todas las condiciones deben ser verdaderas para que la regla actúe.
• Orden: las acciones se ejecutan en el orden en que aparecen en la regla.
• Activar/desactivar: puedes pausar una regla sin eliminarla.

Acciones por disparador

La lista de acciones está acotada por el asunto del disparador: cada disparador ofrece todas las acciones que su asunto puede ejecutar realmente — así armas la regla completa sin combinaciones que nunca se ejecutarían.

• Disparadores de conversación y de mensaje (conversación creada, actualizada, abierta, resuelta y mensaje creado) ofrecen el catálogo completo de acciones.
• Disparadores de contacto (creado/actualizado/fusionado) ofrecen todo el catálogo anclado al contacto: CRM (crear un negocio ya vinculado al contacto, mover etapa), tareas y citas ligadas al contacto, cobros y suscripciones, follow-ups, contratos, engagement, acciones de grupo de WhatsApp (participante por defecto = el contacto), webhook y disparo masivo de flujo. Las acciones que actúan sobre una conversación quedan fuera (no hay conversación) — encadena con Crear conversación.

Suscripciones: qué dispara y qué no

Una suscripción creada en el panel del gateway se adopta aquí y sí dispara la regla: para la plataforma está ocurriendo ahora, ya filtrada por la fecha de corte de la conexión. Una suscripción traída por una importación de historial nunca dispara — es pasado, y reprocesarla abriría negocios y notificaciones sobre ventas antiguas.

La suscripción adoptada puede llegar sin cliente vinculado. Las acciones que dependen de una persona (abrir negocio, enviar mensaje, puntuar) no tienen a quién dirigirse, y un negocio sin contacto, empresa ni conversación se rechaza en lugar de convertirse en una tarjeta inútil en el embudo. Para actuar solo cuando haya alguien del otro lado, añade la condición Contacto vinculado a la suscripción con "está presente".

• Disparador de contacto eliminado: como la ficha dejó de existir, ofrece solo webhook y acciones totalmente controladas por parámetros.
• Disparadores de pedidos anclan en el contacto del pedido — todas las acciones ancladas al contacto quedan disponibles.
• Disparadores de tareas, agenda, grupos de WhatsApp, suscripciones, comercio, contratos, engagement, CRM y anuncios ganaron el catálogo completo que su asunto soporta — incluidas las acciones de conversación cuando el asunto tiene una conversación vinculada (por ejemplo, una tarea con conversación vinculada o un grupo con la conversación del grupo).

Al crear una regla nueva (o cambiar el disparador), el selector ya viene con la primera acción válida de ese disparador preseleccionada — nunca más abres una regla nueva y encuentras "Asignar al Agente · No disponible para este disparador".

Si editas una regla antigua que tiene una acción que ya no pertenece al disparador actual, esa acción sigue visible con la marca "No disponible para este disparador". No se elimina: la regla se puede seguir guardando y puedes cambiarla por una acción compatible cuando quieras.

Acciones sin parámetros

Algunas acciones no piden ningún campo extra porque resuelven el contexto por sí solas a partir del disparador. Se guardan sin exigir parámetros, tanto en Automatizaciones como en Macros:

• Cancelar, pausar, reanudar y saltar paso de follow-up;
• Enviar cobro y cancelar suscripción;
• Enviar tarjeta de producto;
• Pausar campaña de anuncios, enviar conversión y marcar como lead de anuncio.

Cuando una acción no aplica

Si una acción depende de algo que no existe en ese contexto — por ejemplo, una acción de conversación en un disparador que no tiene conversación vinculada — se ignora y se registra, sin romper la regla: las demás acciones se siguen ejecutando normalmente.

Variables en las acciones ({ } Insertar)

Todo campo de texto que la plataforma resuelve al ejecutar muestra el botón { } Insertar y abre la lista de variables cuando escribes {{. La variable elegida entra en la posición del cursor y la ventana de la regla sigue abierta. Los mismos campos aceptan variables en Automatizaciones, Macros y en el Flow Builder — en el flujo, esos campos también resuelven {{ vars.* }} y {{ steps.* }}.

Campos que no aceptan variables, a propósito:

• Selectores (agente, equipo, etiqueta, embudo, etapa, bandeja de entrada, conexión): el valor viene de la lista.
• URL del webhook: el destino es fijo por seguridad; los datos de la conversación o del contacto ya viajan en el cuerpo del webhook.
• Importe de cobros y suscripciones: es dinero enviado a la pasarela y nunca viene de un texto.
• Pasarela del pedido, idioma y namespace de la plantilla: son identificadores.
• Atributos adicionales y los campos numéricos y de fecha del editor de reglas (por ejemplo, el valor del negocio en "Definir valor"): en el formulario del Flow Builder el valor del negocio acepta variable.

Qué variables ofrece la lista depende del disparador:

• Conversación y mensaje: contacto, conversación, bandeja de entrada, agente, equipo, SLA, cuenta y los módulos (CRM, empresa, pago, pedido, agenda, tarea, contrato y otros).
• Contacto y empresa: no hay conversación — la lista oculta conversación, bandeja de entrada, agente, equipo y SLA.
• Pagos: {{ payment.* }} describe el cobro que disparó la regla. CRM: {{ crm.* }} describe el negocio que disparó la regla.
• Los demás módulos ligados al contacto (pedido, agenda, tarea, contrato) usan el registro más reciente del contacto.
• Las reglas y macros nunca ofrecen las variables exclusivas del Flow Builder (vars, steps, trigger) ni las de otras pantallas (producto, campaña, grupo, artículo).

Cuando una variable no tiene valor, ese tramo del texto queda en blanco — el cliente nunca recibe {{ ... }}. En campos que son datos (teléfono, correo del invitado, ids, importes y fechas), la acción se omite y se registra en lugar de guardar un valor incorrecto. El teléfono se normaliza al formato internacional después de resolver la variable, así que 55 11 98888-7777 pasa a +5511988887777.

El valor de una variable siempre se trata como texto: si el nombre del contacto, un atributo o una respuesta del cliente contiene {{ }} o {% %}, aparece exactamente como está — nunca se ejecuta — y en el correo al equipo tampoco se convierte en HTML. Una plantilla que genera demasiado texto o repite sin fin se interrumpe y queda en blanco.

El formulario de la regla

La regla se abre en una ventana modal sobre la lista, anclada en la parte superior de la pantalla y con desplazamiento propio: el formulario completo cabe ahí, desde el nombre hasta las acciones. Los menús de condición y de acción se abren dentro de esa ventana — es una elección deliberada de la plataforma, para que ninguna lista desplegable quede escondida detrás del modal.

El orden de los campos es siempre el mismo: nombre, descripción, el selector ¿Cuándo debe ejecutarse esta regla? (cuando la ejecución diferida está habilitada) y, debajo, el disparador y las condiciones — o el bloque Condición de espera, si eliges la espera. Las acciones van al final, seguidas de los botones de cancelar y guardar.

Algunos detalles que evitan sorpresas:

• Cambiar entre "al instante" y "con espera" no pierde la duración escrita. El valor queda guardado en el formulario, así que puedes ir y volver entre las dos tarjetas sin volver a escribir "4 horas".
• Al reabrir una regla con espera, el tiempo aparece en la mayor unidad entera: 240 minutos se muestran como "4 horas"; 2.880 minutos, como "2 días".
• Al convertir una regla al instante en una regla con espera, las condiciones del editor instantáneo se sustituyen por las condiciones del disparador de espera elegido. Es intencional: un filtro que sobrara del editor anterior armaría el contador en el evento equivocado.
• En el bloque de espera, el estado ya viene con Pendientes; las opciones son Abiertas, Resueltas, Pendientes y Postpuestas — "Todos" no se ofrece aquí, porque una espera necesita un estado concreto contra el cual contar.
• En una regla nueva, cambiar el evento avisa por escrito: "El cambio de tipo de evento restablecerá las condiciones y eventos que has añadido abajo".
• Los disparadores cuyo asunto no tiene ningún campo filtrable (grupo de WhatsApp, catálogo y otros) simplemente no muestran la sección de condiciones — en lugar de mostrar una fila de condición vacía.

Reglas con espera: ejecutar después de un tiempo

La ejecución diferida se controla con la funcionalidad Delayed Automations (delayed_automations), que viene desactivada y se habilita por cuenta. Con ella activa, el formulario de la regla gana el selector ¿Cuándo debe ejecutarse esta regla?, con dos opciones en tarjeta: Ejecutar al instante y Ejecutar después de una espera.

Al elegir la espera, el disparador y la lista de condiciones dan paso al bloque Condición de espera, con cuatro campos:

Junto a los campos hay un panel lateral con el icono de información. Explica en frases completas qué significa la combinación elegida, usando la misma unidad que escribiste ("4 horas", "2 días"):

• La conversación permanece en un estado — "El contador comienza cuando una conversación pasa a este estado. Si continúa en él {duración} después, se ejecutan las acciones siguientes. Si el estado cambia antes, no ocurre nada."
• El cliente no ha respondido — "El contador comienza cuando responde un miembro del equipo. Si el cliente no ha vuelto a escribir {duración} después, se ejecutan las acciones siguientes. Si responde, no ocurre nada y la siguiente respuesta del equipo vuelve a iniciar el contador."
• Ningún miembro del equipo ha respondido — "El contador comienza cuando un cliente envía un mensaje. Si ningún miembro del equipo ha respondido {duración} después, se ejecutan las acciones siguientes. Si alguien responde antes, no ocurre nada."

El mismo panel incluye la nota al pie: "Solo la actividad nueva inicia un contador. Las conversaciones que ya se encuentren en este estado se procesarán la próxima vez que ocurra algo en ellas."

Dos precisiones que el panel no tiene espacio para explicar, y que cambian el resultado:

• En El cliente no ha respondido, cada nueva respuesta del equipo adelanta el vencimiento: el plazo pasa a contarse desde la respuesta más reciente. Una serie de mensajes del equipo empuja el plazo hacia adelante; no acumula varios plazos.
• En Ningún miembro del equipo ha respondido, vale el contador del primer mensaje sin respuesta del cliente. Si envía tres mensajes más seguidos, el plazo sigue contando desde el primero — no se reinicia con cada mensaje.

Límites de la espera

• Mínimo de 10 minutos y máximo de 30 días (43.200 minutos). El campo ajusta solo un valor fuera de ese rango al límite más cercano — al salir del campo, al pulsar Enter o al cambiar de unidad. Escribir 5 minutos deja 10. El error "La espera debe ser de entre 10 minutos y 30 días" aparece al intentar guardar con el campo de duración vacío.
• La duración sugerida en una regla nueva es de 4 horas.
• Al cambiar de unidad, el mínimo acompaña: en días, el menor valor posible es 1 día.
• Una nota privada es un mensaje saliente. Por eso la opción El cliente no ha respondido añade por su cuenta un filtro que ignora las notas internas — una anotación del equipo no reinicia el contador.

Lo que la espera no acepta

• Condiciones con el operador de cambio de atributo (attribute_changed): la revisión que se hace al momento de ejecutar no puede reconstruir qué cambió, así que la regla se rechaza al guardar.
• En los disparadores de conversación, solo estado y bandeja de entrada pueden usarse como condición. Los demás campos cambian durante la espera y mezclarían periodos distintos en un solo contador.

Editar una regla con espera reinicia los contadores en curso

Cambiar el disparador, las condiciones, las acciones o la duración — o simplemente desactivar y reactivar la regla — descarta las esperas ya armadas. Vuelven a armarse en el siguiente evento que coincida. Es intencional: una regla desactivada y reactivada antes del plazo no debe ejecutar justamente las acciones que desactivaste para evitar.

Una única excepción: una espera que ya empezó a ejecutar las acciones no se interrumpe — lo que está en curso no puede devolverse. Todo lo que solo estaba aguardando se descarta.

Cómo la lista separa reglas al instante y con espera

Cuando la cuenta puede crear reglas con espera (o todavía tiene alguna), la lista gana dos pestañas con contador: Se ejecutan al instante y Se ejecutan después de una espera. Crear una regla desde la segunda pestaña abre el formulario con la espera ya seleccionada.

• Cada regla con espera muestra junto al nombre la insignia Se ejecuta después de {tiempo}, escrita en la mayor unidad entera: 30m, 4h, 2d.
• La pestaña de espera sin reglas muestra "Aún no hay reglas que se ejecuten después de una espera".
• Cada fila trae tres iconos de acción, con ayuda al pasar el cursor: Editar, Clonar y Eliminar. En el formulario, cada acción de la regla también tiene su icono (un sobre para la transcripción por correo, una etiqueta para etiquetar, una campana tachada para silenciar, un reloj para posponer, y así sucesivamente) — los mismos iconos aparecen en las Macros.

La lista completa de iconos de acción: persona (asignar agente), personas redondeadas (asignar equipo), persona con X (quitar agente), personas (quitar equipo), etiqueta (etiquetar), etiqueta con menos (quitar etiqueta), sobre (transcripción por correo), avión de papel (correo al equipo), globo (enviar mensaje), bloc de notas (nota privada), clip (adjunto), webhook, campana tachada (silenciar), reloj (posponer), círculo con punto (reabrir), círculo punteado (marcar como pendiente), círculo con marca (resolver), barras de señal (prioridad) y medidor (SLA). Toda acción sin icono propio usa el rayo.

La cabecera trae además la búsqueda ("Buscar reglas de automatización..."), que filtra por nombre y descripción a la vez y vale para las dos pestañas — los contadores acompañan el filtro. Sin resultados, la tabla muestra "No se encontraron reglas de automatización para tu búsqueda". Junto a las pestañas aparece el conteo de las reglas visibles en la pestaña actual.

La tabla tiene cuatro columnas: Nombre, Activo, Creado el y Acciones. La columna de fecha muestra el día; la hora completa aparece al pasar el cursor. El interruptor de Activo pide confirmación antes de activar o desactivar, y la pregunta nombra la regla ("Esta acción desactivará la regla de automatización '...'").

Cuando la espera está desactivada

Si la funcionalidad se desactiva y la cuenta todavía tiene reglas con espera, aparece un aviso destacado encima de la lista: "La ejecución diferida está desactivada para esta cuenta, por lo que las reglas siguientes que se ejecutan después de una espera permanecerán en pausa hasta que vuelva a activarse."

En ese estado:

• Las esperas ya armadas no se borran — quedan detenidas. Al reactivar la funcionalidad, las que superaron el límite de 3 días durante la pausa reciben un plazo nuevo para ahora, en lugar de descartarse por vencimiento; las demás simplemente entran en la siguiente barrida. Todas pasan por la revisión normal antes de ejecutarse.
• No se arma ninguna espera nueva y la regla no pasa a ejecutarse al instante: volverse instantánea en silencio sería peor que no ejecutarse.
• Clonar una regla con espera se rechaza, en lugar de crear una copia que se dispararía de inmediato. En pantalla aparece el aviso genérico "No se pudo clonar la regla de automatización, por favor inténtalo más tarde"; el motivo específico llega en la respuesta de la API ("Delayed automations are not enabled for this account.").

Cómo se ejecuta la espera entre bastidores

Saber esto ayuda a interpretar lo que ves en pantalla:

1. Cuando ocurre el evento y las condiciones se cumplen, la plataforma programa la ejecución en lugar de ejecutar las acciones. El contador parte del momento del evento — no del momento en que se procesó — así que una cola atrasada igual se dispara a tiempo.
2. Cada 5 minutos un barrido recoge las ejecuciones vencidas y las entrega a los procesadores.
3. Antes de ejecutar, la plataforma vuelve a comprobarlo todo: ¿la regla sigue activa? ¿La conversación todavía existe? ¿Sigue siendo el mismo periodo (el estado no cambió, nadie respondió)? ¿Las condiciones siguen siendo verdaderas? Cualquier "no" registra el motivo y descarta la ejecución sin ejecutar las acciones.
4. Una ejecución con más de 3 días de vencimiento nunca se ejecuta — eso evita que una caída larga vuelque mensajes antiguos de golpe. Los registros ya cerrados se purgan a los 30 días.
5. Las acciones nunca se repiten: si algo falla después de que empezaron, la plataforma no las vuelve a ejecutar. Reenviar un mensaje, un correo o un webhook es peor que no enviarlo.

Dos salvaguardas completan el cuadro:

• Cada barrido entrega como máximo 1.000 ejecuciones. El excedente queda para el barrido siguiente, 5 minutos después, y quien administra la instalación puede cambiar ese tope. Las cuentas con la ejecución diferida desactivada no consumen esa cuota — la acumulación de una cuenta en pausa nunca retrasa a las demás.
• Un procesador que muera antes de actuar tiene su ejecución recuperada a los 15 minutos y devuelta a la cola. Un procesador que muera en medio de las acciones no se repite, por la misma razón del punto 5.

Toda ejecución descartada guarda el motivo, lo que hace directo el diagnóstico: expired (pasó de los 3 días), rule_inactive (la regla se desactivó), conversation_gone (la conversación ya no existe), episode_moved (el periodo terminó — alguien respondió o el estado cambió) y conditions_changed (una condición dejó de ser verdadera).

Un detalle que explica la nota al pie del panel: una espera por estado solo se arma cuando la conversación tiene registro de cuándo entró en su estado actual. Las conversaciones anteriores a la funcionalidad no tienen ese registro — empiezan a contar en su siguiente cambio de estado, en lugar de vencer todas de golpe en el primer barrido.

Enviar la transcripción al correo del contacto

La acción Enviar transcripción por correo acepta una lista de direcciones separadas por comas, y cada dirección pasa por variables antes del envío. Para enviar el historial al propio cliente, escribe:

{{contact.email}}

Puedes combinar variable y dirección fija: {{contact.email}}, supervision@tuempresa.com. Otras variables del contacto también funcionan en este campo (por ejemplo {{contact.custom_attribute.correo_factura}} para un atributo personalizado). Usa la variable solo en reglas cuyas condiciones garanticen un contacto con correo registrado — sin correo no hay nada que resolver. El envío solo ocurre cuando la transcripción por correo está habilitada para la cuenta, y respeta el límite de correos de la cuenta.

Dos detalles del campo: todo espacio en blanco se elimina antes de separar la lista por las comas — {{contact.email}} , supervision@tuempresa.com funciona igual que la versión sin espacios. Y el campo resuelve el mismo conjunto de variables que el compositor de respuesta (contacto, conversación, bandeja de entrada, cuenta y los módulos activos), no solo las del contacto. Si la cuenta alcanza su límite de correos a mitad de la lista, las direcciones restantes de ese envío quedan fuera.

Casos de uso

• Enrutamiento por canal: las conversaciones creadas en el WhatsApp comercial van al equipo de Ventas.
• Triaje por palabra clave: si el mensaje contiene "factura", añadir la etiqueta "facturación".
• Fuera de horario: al crear una conversación fuera del horario laboral, enviar un mensaje automático.
• Higiene de la cola: resolver conversaciones sin respuesta desde hace mucho tiempo y notificar al equipo.
• CRM: al crear una conversación de un lead, crear un negocio y asignarlo al vendedor responsable.
• El cliente se quedó callado (con espera): si el cliente no responde 4 horas después de la última respuesta del equipo, etiquetar como "sin respuesta" y crear una tarea de seguimiento.
• Primera respuesta con retraso (con espera): si ningún miembro del equipo responde en 30 minutos, avisar al equipo por correo y subir la prioridad.
• Cola detenida (con espera): una conversación en "Pendiente" desde hace 2 días, resolverla y enviar la transcripción al correo del contacto.

Consejos, límites y buenas prácticas

• Usa nombres descriptivos y mantén cada regla enfocada en un solo objetivo.
• Evita reglas en conflicto que intentan hacer cosas opuestas en la misma conversación.
• Para acciones que envían mensajes automáticos, respeta los límites del canal (buenas prácticas anti-ban de WhatsApp).
• Prueba en una bandeja de pruebas antes de aplicar la regla en producción.
• Documenta para el equipo qué hace cada regla — facilita el mantenimiento futuro.
• Empieza con esperas generosas (horas, no minutos) y acórtalas después de ver el resultado: una espera demasiado corta se dispara sobre conversaciones que todavía se estaban atendiendo.
• La espera es un contador continuo, no un reloj de horario laboral: 12 horas iniciadas a las 20:00 vencen a las 8:00 del día siguiente.
• Al habilitar la ejecución diferida, las conversaciones que ya están detenidas en ese estado no empiezan a contar solas — el contador arranca en su siguiente actividad.
• Restringe la regla por bandeja de entrada cuando el tiempo de respuesta aceptable varíe según el canal.

Solución de problemas

• La regla no se disparó: confirma el disparador y que todas las condiciones sean verdaderas; verifica que la regla esté activa.
• La acción no se ejecutó: comprueba que el agente, equipo o etiqueta referidos todavía existan; y que el módulo de la acción (CRM, Catálogo, etc.) esté habilitado.
• La regla actuó en la conversación equivocada: las condiciones son demasiado amplias. Refina los filtros.
• Una acción se ignoró: algunas acciones solo se ejecutan cuando hay una conversación en el contexto del disparador; fuera de eso, se registran y se ignoran sin interrumpir la regla. Prefiere una acción compatible con el disparador elegido.
• Una acción muestra un valor bloqueado, solo un número: la acción apunta a un registro de un módulo que está desactivado en la cuenta o al que tu perfil no tiene acceso (por ejemplo, una secuencia de follow-up o una política de SLA). Un valor bloqueado también puede significar que la lista aún no cargó, que la consulta falló o que la lista de tu perfil de acceso no incluye el registro (puede estar fuera de tu alcance o haber sido eliminado). La ayuda explica la causa. La referencia queda sin cambios al guardar otras modificaciones. Recarga la página para repetir una consulta fallida; si el acceso está restringido, pide ayuda a quien tenga acceso o vuelve a activar el módulo.
• Una acción muestra un número en lugar del nombre: el registro puede estar fuera de la página cargada de una lista larga o haber sido eliminado. Un lote preparado también puede aparecer solo por su identificador. Cuando una consulta confirma la eliminación, el campo lo identifica como eliminado. El valor sigue seleccionado y se guarda sin cambios; elige otro elemento solo si quieres cambiarlo.
• El webhook no llegó: revisa la URL del endpoint y que responda correctamente.
• La regla con espera nunca se ejecutó: el motivo más común es que el periodo terminó antes del plazo — alguien respondió, el estado cambió o una condición dejó de ser verdadera. Comprueba también que la regla siga activa y que la conversación todavía exista.
• Todas las reglas con espera se detuvieron a la vez: busca el aviso encima de la lista. Indica que la ejecución diferida se desactivó para la cuenta; al reactivarla, las esperas vencidas se reprograman.
• Quiero saber por qué se descartó una espera: el motivo queda registrado en la propia ejecución — expired, rule_inactive, conversation_gone, episode_moved o conditions_changed. Pide a quien administra la instalación que lo consulte cuando el comportamiento no esté claro.
• Las esperas están venciendo con retraso: cada barrido entrega hasta 1.000 ejecuciones y se ejecuta cada 5 minutos. Una acumulación mayor se drena en los barridos siguientes.
• No puedo guardar la espera: elimina las condiciones con el operador de cambio de atributo y, en los disparadores de conversación, mantén solo estado y bandeja de entrada.
• No puedo clonar una regla con espera: el aviso genérico de fallo al clonar aparece porque la funcionalidad está desactivada en la cuenta. Reactívala antes de clonar, para no generar una copia que perdió su espera.
• El bloque de espera no aparece en el formulario: la funcionalidad Delayed Automations no está habilitada para la cuenta.

Cambios de etapa del CRM

Usa Etapa del negocio del CRM modificada y selecciona la etapa en las condiciones. La regla se activa únicamente al cambiar de etapa; reordenar una tarjeta dentro de su columna no inicia otra ejecución.

Los adjuntos (incluido PDF) y las conversiones Meta usan la conversación vinculada al negocio. Si falta el vínculo, la acción se registra como omitida; el webhook puede ejecutarse independientemente. Revisa la configuración de conversiones de la bandeja y adjunta los archivos a la propia regla. Encolar una conversión no prueba que Meta la haya aceptado: revisa también su registro de entrega.

Para la ejecución diferida, el plazo comienza al cambiar de etapa. Antes de ejecutar, el sistema comprueba de nuevo la etapa, las condiciones y que la regla siga activa. Pausar la función conserva las acciones pendientes. Al reactivarla se retoman las elegibles; las que vencieron hace más de tres días se marcan como expiradas. Editar o desactivar la regla cancela las acciones pendientes de su definición anterior.

Cada acción conserva su resultado. Repetir el evento o reiniciar el worker no repite las acciones completadas. Si una integración externa pudo ejecutarse antes de una falla, su resultado permanece incierto y debe verificarse antes de reenviar. No reproduzcas cambios históricos de etapa de forma masiva para recuperar una regla: podrías volver a disparar efectos comerciales válidos.

Ver también

• Visión general de Automatización y Flujos
• Disparadores de automatización sobre la IA (Maestro)
• Macros: acciones reutilizables
• Flow Builder: flujos conversacionales visuales
• Enrutamiento inteligente (Smart Routing)