Skip to main content
Esta guía muestra cómo crear, gestionar y diagnosticar reglas de automatización. Para el modelo conceptual (triggers, conditions, actions), ver Visión General.

​
Creando una regla

  1. Accede a Configuración → Automatización.
  2. Haz clic en Nueva Regla.
  3. Dale un nombre descriptivo (ej.: “Asignar leads de WhatsApp al equipo comercial”).
  4. Elige un trigger de la lista.
  5. (Opcional) Añade conditions para filtrar cuándo la regla debe disparar.
  6. Añade una o más actions.
  7. Activa la regla.

​
Tips para nombres

  • Comienza con el verbo de la acción principal (Asignar..., Mover..., Etiquetar...).
  • Incluye el contexto (canal, equipo, etapa) para que otros operadores entiendan sin abrir el detalle.
  • Evita nombres genéricos como “Regla 1” o “Auto” — vas a acumular docenas y necesitas encontrarlas por búsqueda.

​
Conditions y templates de mensaje

Las conditions usan el sistema de variables de template cuando necesitas hacer comparaciones dinámicas. A partir de v1.0.0-rc3 (EVO-1146), las variables ganaron campos adicionales:
  • label, source, example, position, component
Usa estos campos en las conditions para expresiones más precisas. Por ejemplo: filtrar por una label específica usando el label.title resuelto en vez del UUID crudo.

​
Operador attribute_changed con From/To

Cuando quieres disparar regla solo en una transición específica de atributo (ej.: “status cambió de pendiente a calificado”), usa el operador attribute_changed con los pickers explícitos de valor antes y valor después.

​
Actions con payload dinámico

​
send_template

Permite enviar un template de mensaje con variables completadas dinámicamente. El sistema usa deep_stringify_keys en el payload para que la llamada funcione independiente del shape de las keys (string o symbol).

​
send_canned_response

Atajo para enviar una respuesta predefinida registrada en Configuración → Respuestas Predefinidas. El payload acepta variables sustituidas con datos de la conversación.

​
move_to_pipeline (rc3)

Mueve el ítem de pipeline a otro pipeline preservando el id del ítem. Útil para reglas tipo “si label calificado fue añadida en el pipeline Leads, mover al pipeline Ventas”.
La action hace bypass de la validación same-pipeline automáticamente. No confundas con move_to_stage, que mueve dentro del mismo pipeline.

​
apply_label

A partir de v1.0.0-rc3, la action muestra un picker de labels en lugar de campo de texto libre. UUIDs son resueltos a títulos antes de etiquetar, con fallback caso la label haya sido renombrada.

​
Panel de Logs (rc3)

Cada ejecución de regla ahora genera un registro en el panel Automatización → Logs. Ves:
  • Cuándo la regla disparó.
  • Qué conversación / ítem la accionó.
  • Conditions evaluadas — cuáles pasaron y cuáles no.
  • Actions ejecutadas — éxito o error.
  • Errores emergidos — incluyendo fallas en macro webhooks (que antes quedaban silenciosas, ver EVO-1041).

​
Limpieza automática

Logs antiguos son removidos por un cleanup job que corre periódicamente. No necesitas borrar manualmente.

​
Endpoint de API

Para consumir logs programáticamente (dashboards externos, alertas), usa el endpoint de listado de automation_rule_runs. Ver la API Reference para el schema completo.

​
Diagnóstico de reglas que no disparan

Roadmap rápido cuando una regla parece no estar funcionando:
  1. Verifica si está activa. Reglas desactivadas no aparecen como error — simplemente no corren.
  2. Confirma el trigger. conversation_updated cubre varios casos, pero attribute_changed es específico.
  3. Mira el log de la ejecución. En el panel de logs, filtra por la regla. Si aparece con “no match”, tus conditions están filtrando.
  4. Conditions con label. La condition labels usa subquery EXISTS (independiente y NULL-safe) y empareja label en conversation O contact. Si esperabas emparejamiento solo en la conversación, restringe con otra condition.
  5. Dedup. Para pipeline_stage_updated, hay ventana de 5s — dos eventos en el mismo (rule, pipeline_item, stage) en ventana corta se ejecutan solo una vez.

​
Loop prevention

Cuando una regla move_to_stage acciona un evento pipeline_stage_updated que podría disparar la misma regla recursivamente, el sistema marca la ejecución con Current.executed_by = :stage_automation e ignora reentradas. Esto evita loops infinitos por diseño.

​
Consideraciones Finales

Las automation rules son la forma declarativa de codificar comportamiento operacional del CRM. Para flujos más complejos que involucren IA conversacional, considera combinar una automation rule con un agente — la regla cuida del routing y el agente cuida del diálogo.