Automatización en SuiteCRM: workflows, schedulers y logic hooks para tu negocio

Uno de los puntos fuertes de SuiteCRM frente a otras soluciones CRM es su potente motor de automatización. Los Workflows (flujos de trabajo) permiten automatizar tareas repetitivas, asignar registros, enviar notificaciones y ejecutar lógica de negocio sin escribir una línea de código. En SuiteCRM 8.x, los workflows se han mejorado significativamente con una interfaz más intuitiva y nuevas capacidades.

Esa es la teoría. En la práctica, buena parte de las instalaciones de SuiteCRM que nos llegan a revisar aprovechan solo una fracción de ese motor: tres o cuatro workflows heredados de la puesta en marcha, ningún scheduler propio más allá de los que trae el sistema, y un montón de trabajo manual que alguien repite cada mañana porque siempre se ha hecho así. Ese coste no aparece en la factura del CRM: aparece en las horas del equipo comercial y en los seguimientos que se caen.

Esta guía recorre las tres capas de automatización de SuiteCRM —workflows, schedulers y logic hooks—, cuándo conviene cada una, los casos de uso que más repetimos en proyectos reales y los errores que encontramos al revisar instalaciones ajenas. Si todavía estás decidiendo plataforma, merece la pena empezar por la comparativa entre SuiteCRM, Odoo y Pipedrive; si vienes de otro CRM, tenemos guías específicas para migrar desde Salesforce y para migrar desde HubSpot.

Antes de automatizar: qué procesos merecen la pena

Automatizar un proceso mal definido no lo arregla: lo acelera. Antes de abrir el panel de workflows conviene pasar los candidatos por cuatro filtros sencillos.

• Frecuencia: algo que ocurre cien veces al mes justifica una hora de configuración; algo que ocurre dos veces al año, normalmente no.
• Determinismo: si la decisión depende del criterio de una persona, automatiza el aviso y la preparación del contexto, no la decisión.
• Coste del error: un workflow que reasigna registros mal configurado puede dejar oportunidades sin dueño. Cuanto mayor es el impacto, más riguroso tiene que ser el paso por un entorno de pruebas.
• Estabilidad del proceso: si el equipo comercial cambia de criterio cada trimestre, el workflow se convierte en mantenimiento permanente. En esos casos es mejor dejar la lógica en campos y vistas configurables.

De ese ejercicio suele salir una lista corta y muy rentable: asignación de leads, recordatorios de seguimiento, cambios de estado por inactividad y notificaciones internas. Es justo lo que cubren los casos de uso de más abajo.

Una recomendación adicional: documenta el proceso antes de automatizarlo, aunque sea en media página. En auditorías técnicas es habitual encontrar workflows activos que nadie sabe explicar y que nadie se atreve a desactivar. Si quieres ver cómo abordamos ese tipo de revisión, lo contamos en nuestra página de auditoría técnica.

Tipos de automatización en SuiteCRM

1. Workflows

Los workflows se disparan cuando se crea o modifica un registro y ejecutan acciones automáticas:

• Crear registro: Generar automáticamente una tarea, llamada o meeting cuando se crea una oportunidad.
• Modificar campos: Cambiar el estado de un lead cuando se completa una actividad.
• Enviar email: Notificaciones automáticas a vendedores, managers o clientes.
• Calcular campos: Rellenar campos calculados basados en otros valores del registro.

Tipos de disparo:

• Only on save: Se ejecuta cada vez que se guarda el registro (si cumple las condiciones).
• Only on first save: Solo se ejecuta cuando el registro se crea por primera vez.
• After time elapsed: Se ejecuta X horas/días después de la creación o modificación.

Dos detalles que marcan la diferencia al configurarlos. El primero es la opción de ejecuciones repetidas: un workflow marcado para repetirse volverá a actuar cada vez que el registro cumpla las condiciones, lo que es justo lo que quieres en un recordatorio recurrente y justo lo que no quieres en un email de bienvenida. El segundo es que las condiciones aceptan comparaciones contra el valor anterior del campo, no solo contra el actual: así puedes disparar solo cuando un estado pasa de una fase a otra, en lugar de cada vez que se guarda un registro que ya estaba en esa fase.

Los workflows son también el sitio natural para la lógica que el equipo de negocio debe poder tocar sin pedir un despliegue. Si una regla de asignación depende de territorios que cambian cada año, es mejor que viva en un workflow editable desde el panel que en código.

2. Schedulers (tareas programadas)

Procesos que se ejecutan periódicamente vía cron:

• Ejecutar workflows pendientes con condición de tiempo.
• Enviar campañas de email marketing.
• Sincronizar datos con sistemas externos.
• Limpieza automática de registros antiguos.
• Generación de reportes periódicos.

Hay un punto que conviene no pasar por alto: si el cron del servidor no está correctamente configurado, nada de esto ocurre. Los workflows con disparo after time elapsed, las campañas y los informes programados dependen todos del planificador de SuiteCRM, que a su vez necesita que el sistema operativo invoque su proceso cada pocos minutos. Es, con diferencia, la causa número uno de la frase «el workflow no funciona» en soporte: el workflow está bien, pero nadie lo está ejecutando.

Por eso, al revisar una instalación comprobamos siempre tres cosas en este orden: que existe la entrada de cron, que el usuario que la ejecuta tiene permisos sobre los ficheros del CRM, y que la pantalla de planificador muestra una última ejecución reciente en cada tarea activa. Si la última ejecución es de hace semanas, el problema no está en la lógica de negocio.

Los schedulers también son el lugar correcto para los procesos pesados. Un recálculo masivo o una sincronización de miles de registros no debe colgar del guardado de un formulario: se programa fuera de horario y se registra su resultado.

3. Logic Hooks

Para desarrolladores: hooks PHP que se ejecutan en eventos del ciclo de vida de un registro:

• before_save: Validar o transformar datos antes de guardar.
• after_save: Ejecutar lógica post-guardado (sincronizar con API externa, crear registros relacionados).
• before_delete: Verificar dependencias antes de eliminar.
• after_relationship_add: Actuar cuando se vinculan registros.

La regla práctica para elegir entre workflow y logic hook es sencilla: si la lógica se puede expresar como «cuando se cumpla X, haz Y» con un puñado de condiciones, es un workflow; si necesita bucles, llamadas a servicios externos, manejo de errores o transformaciones de datos, es un logic hook. Intentar forzar la segunda en la primera produce cadenas de workflows encadenados imposibles de depurar.

4. Automatización desde fuera: API REST y orquestadores

Existe una cuarta vía que no vive dentro de SuiteCRM pero que en proyectos reales resuelve buena parte del trabajo: orquestar el CRM desde una herramienta externa a través de su API REST. En lugar de programar la integración entera en PHP, un orquestador como n8n, Make o Zapier escucha un evento en otro sistema (una compra, un alta, un ticket) y escribe en SuiteCRM, o al contrario.

Esta capa es la más adecuada cuando el proceso cruza varios sistemas: el CRM, el ERP, la tienda online y el correo. Lo hemos desarrollado en detalle en la guía de n8n para sincronizar CRM y ERP, y conviene leerla junto a las buenas prácticas de seguridad en n8n, porque un orquestador acumula credenciales de todos los sistemas que toca. Si lo que necesitas es conectar el CRM con asistentes de IA, el protocolo MCP y el caso concreto de Claude aplicado a SuiteCRM cubren ese terreno.

El criterio de reparto que seguimos: lo que es puramente interno al CRM se queda en workflows; lo que cruza sistemas se externaliza al orquestador, donde hay logs, reintentos y control de errores de serie.

Casos de uso reales

Asignación automática de leads

Cuando entra un lead nuevo desde el formulario web:

1. Workflow detecta nuevo lead.
2. Evalúa el campo «País» o «Sector».
3. Asigna al vendedor correspondiente según territorio.
4. Crea una tarea de seguimiento para las próximas 24h.
5. Envía notificación al vendedor asignado.

En la implementación hay dos decisiones que determinan si esto funciona a medio plazo. La primera es qué pasa cuando ningún criterio encaja: siempre debe existir una regla por defecto que asigne el lead a una cola o a un responsable comercial, porque un lead sin propietario es un lead que nadie reclama. La segunda es la disponibilidad: si el vendedor de ese territorio está de baja o de vacaciones, la asignación debería recaer en un suplente. Resolverlo con un campo de usuario activo y una condición adicional cuesta diez minutos y evita semanas de leads en el limbo.

Escalado de oportunidades

Si una oportunidad de alto valor lleva más de 7 días sin actividad:

1. Workflow con condición de tiempo detecta inactividad.
2. Envía alerta al manager del vendedor.
3. Crea tarea urgente de seguimiento.
4. Actualiza el campo «Riesgo» a «Alto».

Conviene definir «sin actividad» con precisión. La fecha de última modificación del registro no sirve: cambia con cualquier edición menor. Lo que mide el estado real del trato es la última llamada, reunión o email registrados; si tu instalación no los relaciona bien con la oportunidad, el workflow dará falsos positivos y el equipo dejará de hacer caso a las alertas, que es el peor desenlace posible para una automatización de este tipo.

Onboarding automático de clientes

Cuando una oportunidad pasa a estado «Cerrada Ganada»:

1. Crear caso/proyecto de onboarding.
2. Asignar al equipo de customer success.
3. Enviar email de bienvenida al cliente.
4. Crear tareas del checklist de onboarding.
5. Programar llamada de kickoff.

Este es el caso donde el disparo importa más. Si el workflow se configura como only on save con la condición «estado = Cerrada Ganada» y además se permiten ejecuciones repetidas, cada edición posterior de esa oportunidad volverá a crear el proyecto y a enviar el email de bienvenida. La combinación correcta es comparar contra el valor anterior del campo y desactivar la repetición: el proceso debe dispararse en la transición, una sola vez.

Nurturing de leads fríos

Si un lead no ha tenido actividad en 30 días:

1. Añadir a lista de target de campaña de re-engagement.
2. Cambiar estado a «Reciclado» si no responde en 60 días.

Al automatizar envíos a listas de contactos hay que tener presente la dimensión legal: el consentimiento y la trazabilidad de la baja no son opcionales, y la lista de destino debe respetar las exclusiones. Un workflow que reañade a un contacto que se dio de baja es un problema de cumplimiento, no un detalle técnico.

Avisos de renovación y recurrencia

Para negocios con contratos o suscripciones, el patrón más rentable no es comercial sino de retención: un scheduler revisa a diario los contratos cuya fecha de fin cae dentro de los próximos 60 días, crea una tarea de renovación con el histórico del cliente adjunto y avisa al responsable de cuenta. Es una automatización de quince minutos que evita renovaciones perdidas por olvido. Si gestionas cobros periódicos, la lógica de negocio que hay detrás la tratamos en el artículo sobre suscripciones y pagos recurrentes.

Deduplicación y calidad de datos

La automatización menos vistosa y la que más agradece el equipo. Un scheduler nocturno que marque registros con email o teléfono duplicado, cuentas sin propietario, o leads creados sin origen asignado mantiene el CRM utilizable. Los informes que dependen de esos datos solo valen lo que valga la disciplina de entrada, y una revisión automática diaria sustituye una limpieza manual trimestral. Si el punto de partida es una base muy sucia, el proceso de carga inicial lo cubrimos en la guía de importación masiva desde Excel y Access.

Cómo se configura un workflow paso a paso

El recorrido es siempre el mismo, y entenderlo evita la mitad de los problemas posteriores. Desde el panel de administración se crea una definición de workflow con estos elementos:

1. Nombre y descripción: usa una convención del tipo [Módulo] Acción — Disparo. «Leads: asignar por territorio — alta» se entiende dentro de dos años; «WF nuevo 3» no.
2. Módulo objetivo: el módulo sobre cuyos registros actúa (Leads, Oportunidades, Casos, Contactos…).
3. Estado: activo o inactivo. Crear siempre inactivo y activar cuando las condiciones estén revisadas.
4. Momento de ejecución: al guardar el registro, en la pasada del planificador, o ambos. Esta elección es la que determina si el workflow depende del cron.
5. Ejecuciones repetidas: si se permite que el mismo registro vuelva a dispararlo. Desactivado por defecto salvo que el caso lo exija.
6. Condiciones: los criterios que el registro debe cumplir, comparando contra un valor fijo, otro campo, o el valor anterior del propio campo.
7. Acciones: qué hace cuando se cumplen las condiciones: crear registro, modificar campos, enviar email con plantilla, o lanzar una notificación.

Antes de activarlo, el guion de pruebas mínimo que usamos es este: crear un registro que cumpla las condiciones y verificar que actúa; crear uno que no las cumpla y verificar que no actúa; editar un registro ya procesado y comprobar que no se vuelve a disparar; y revisar que las acciones no han dejado registros huérfanos. Los cuatro pasos, en un entorno de pruebas, nunca en producción.

Buenas prácticas

• Documentar cada workflow: Nombre descriptivo, condiciones de disparo, acciones. Los workflows sin documentar se convierten en deuda técnica.
• Evitar bucles: Un workflow que modifica un registro puede disparar otro workflow. Usar condiciones específicas para evitar recursión.
• Testing en staging: Probar workflows con datos de prueba antes de activar en producción.
• Monitorizar rendimiento: Workflows complejos con muchas condiciones pueden ralentizar el guardado de registros.
• Usar Logic Hooks para lógica compleja: Si un workflow necesita más de 3-4 condiciones y acciones, probablemente es mejor un Logic Hook custom.

Cómo evitar los bucles en la práctica

La recursión entre workflows es el fallo más caro porque no se nota al configurarlo: se nota semanas después, cuando el guardado de un registro tarda varios segundos o cuando el buzón de un comercial recibe cuarenta avisos idénticos. Tres medidas lo previenen casi siempre: no permitir ejecuciones repetidas salvo que el caso lo requiera; condicionar sobre el valor anterior del campo para que el workflow actúe solo en la transición; y, cuando dos workflows se tocan, usar un campo técnico de control (una marca de «ya procesado») que el segundo compruebe antes de actuar.

Trazabilidad y plan de vuelta atrás

Toda automatización que modifique datos debería dejar rastro. Lo mínimo es una nota o un campo de auditoría que indique qué workflow tocó el registro y cuándo; sin eso, reconstruir qué ocurrió es imposible. Y antes de activar un workflow que actúe sobre registros existentes en masa, conviene tener una copia reciente de la base de datos: un criterio mal escrito puede recorrer miles de filas en segundos. Nuestra recomendación general de copias está en el artículo sobre la estrategia 3-2-1 de backup, y aplica igual a un CRM que a cualquier otro sistema de negocio.

Permisos y seguridad

Un workflow se ejecuta con privilegios del sistema, no con los del usuario que guardó el registro. Eso significa que puede escribir en campos que el usuario no podría editar y enviar correos en nombre de la organización. Revisa quién puede crear o modificar definiciones de workflow: en la práctica, ese permiso equivale a poder modificar datos de forma masiva. Y revisa también las plantillas de email que usan, porque son el camino más directo para que información interna salga fuera por error.

Logic hooks en la práctica

Cuando la lógica se va de lo que un workflow puede expresar, los logic hooks son la vía correcta. Se declaran en un fichero bajo el directorio de personalizaciones del módulo, de forma que las actualizaciones de SuiteCRM no los sobrescriban. La declaración tiene esta forma:

<?php
// custom/modules/Leads/logic_hooks.php

$hook_version = 1;
$hook_array['before_save'][] = array(
    10,                                   // orden de ejecución
    'Normalizar telefono del lead',       // etiqueta
    'custom/modules/Leads/LeadHooks.php', // fichero
    'LeadHooks',                          // clase
    'normalizarTelefono'                  // método
);

Y la clase correspondiente recibe el objeto del registro y el evento:

<?php
class LeadHooks
{
    public function normalizarTelefono($bean, $event, $arguments)
    {
        if (empty($bean->phone_work)) {
            return;
        }
        $limpio = preg_replace('/[^0-9+]/', '', $bean->phone_work);
        if (strlen($limpio) === 9) {
            $limpio = '+34' . $limpio;
        }
        $bean->phone_work = $limpio;
    }
}

Cuatro reglas que nos han ahorrado muchos problemas con hooks. Uno: nunca llamar a save() dentro de un hook de guardado sin control, porque es la vía rápida a una recursión infinita. Dos: todo lo que dependa de un servicio externo va en after_save y con tiempo de espera acotado, para que una API lenta no bloquee el formulario del comercial. Tres: el código vive siempre en el directorio de personalizaciones y, a ser posible, en control de versiones. Cuatro: registra los errores en un log propio; un hook que falla en silencio corrompe datos sin que nadie lo sepa. El criterio general sobre cómo gestionar credenciales en este tipo de integraciones lo tratamos en la guía de gestión de secretos en desarrollo.

SuiteCRM 8.x: mejoras en automatización

La versión 8 de SuiteCRM ha mejorado el sistema de workflows:

• Interfaz de diseño de workflows más visual e intuitiva.
• Mejor rendimiento en la ejecución de workflows masivos.
• API REST mejorada para integración con herramientas externas de automatización (Zapier, n8n, Make).
• Logs más detallados para debugging de workflows.

Situación de las versiones a cierre de 2026

La rama estable actual es la 8.9.x, que ha ido recibiendo versiones de mantenimiento sucesivas —8.9.1, 8.9.2 y 8.9.3— con correcciones y parches de seguridad. La rama 7, que sigue en producción en muchas instalaciones, continúa con mantenimiento de seguridad en sus líneas 7.15.x y 7.14.x. Las novedades funcionales de la 8.9, incluida la renovación del módulo de campañas, las repasamos en el artículo sobre SuiteCRM 8.9.

Dos consideraciones prácticas si estás planificando la subida de versión. La primera: los parches de seguridad son el motivo principal para actualizar, por encima de cualquier novedad de interfaz; un CRM contiene datos personales de clientes y queda dentro del alcance de cualquier política de protección de datos. La segunda: antes de tocar la versión de PHP del servidor, consulta la matriz de compatibilidad oficial de SuiteCRM para tu rama, porque el salto de versión del lenguaje es una causa habitual de roturas en instalaciones con personalizaciones. Si te toca ese trabajo, en la guía de migración a PHP 8.4 y 8.5 explicamos cómo abordarlo sin sorpresas.

En cualquier actualización, los logic hooks y las personalizaciones son lo primero que hay que verificar: viven fuera del núcleo precisamente para sobrevivir a las actualizaciones, pero dependen de métodos y estructuras que pueden cambiar entre ramas mayores.

Errores que encontramos al auditar automatizaciones de SuiteCRM

Este es el resumen de lo que más repetimos al revisar instalaciones que no hemos montado nosotros.

• Cron mal configurado o parado: los workflows con condición de tiempo, las campañas y los informes programados no se ejecutan. Es el primer sitio donde mirar cuando «algo no salta».
• Workflows huérfanos: definiciones activas creadas por alguien que ya no está en la empresa, sin descripción, que nadie se atreve a desactivar. Suelen ser también la causa de notificaciones que el equipo ya filtra como ruido.
• Repetición activada por descuido: emails de bienvenida enviados varias veces al mismo cliente, o proyectos de onboarding duplicados.
• Lógica de negocio metida a presión en workflows: cadenas de ocho o diez definiciones que se disparan entre sí para emular algo que debería ser un logic hook de treinta líneas.
• Plantillas de email desactualizadas: con nombres de personas que ya no trabajan en la empresa, enlaces caídos o condiciones de baja que no reflejan la política actual.
• Cero trazabilidad: ningún campo ni nota que indique qué automatización modificó un registro, lo que convierte cualquier incidente de datos en una investigación a ciegas.
• Personalizaciones en el núcleo: hooks o ficheros modificados fuera del directorio de personalizaciones, que desaparecen en la siguiente actualización.

Ninguno de estos problemas es grave por separado. El patrón que hace daño es acumularlos durante años sin que nadie revise el conjunto: el CRM sigue funcionando, pero el equipo deja de confiar en lo que le dice, y a partir de ahí vuelve el trabajo manual en hojas de cálculo paralelas. Una revisión anual de las definiciones activas, con la lista de arriba como guion, evita casi todo.

¿Necesitas automatizar tu CRM?

En Keliam configuramos y desarrollamos automatizaciones en SuiteCRM: desde workflows simples hasta Logic Hooks complejos con integración de APIs externas. Contacta con nosotros para optimizar tus procesos.