Correo en SuiteCRM 8: interfaz, planificador y flujos de trabajo
- Una prueba correcta desde administración comprueba sobre todo la ruta interactiva, no necesariamente la del planificador o del flujo de trabajo.
- Tras actualizaciones menores cambian requisitos de colas, datos SMTP guardados o ejecución de tareas; existen numerosos informes en foros, dependientes de la versión.
- El correo estable es el resultado operativo de configuración CRM, cron del sistema, límites del proveedor y lógica funcional.
Envío de caja negra
Cola, estado y diagnóstico
Límites del proveedor y envíos masivos
Muchos proveedores SMTP limitan o bloquean al superar cuotas. Sin colas ni gestión de errores, el resto se interrumpe o deja lagunas difíciles de reconstruir. Las cifras dependen del proveedor: consulte su documentación y su propia monitorización.
El correo en SuiteCRM no es una única función, sino una conexión entre interfaz, procesamiento en segundo plano y proveedor externo. Por eso los informes cotidianos suelen parecer contradictorios: Manualmente funciona; automáticamente, no.
1. Tres rutas que los equipos confunden
| Ruta | Activación | Dependencias | Error de interpretación habitual |
|---|---|---|---|
| Interfaz / Redacción / Prueba administrativa | Una persona pulsa ahora | Sesión, permisos y cuenta saliente actual | «SMTP funciona globalmente» |
| Planificador | Cron / Tareas programadas | Cron del sistema, estado de tareas, usuario CLI y cola | «Si cron funciona, los correos también» |
| Flujo de trabajo | Guardado o programación temporal | Momento del desencadenante, condiciones y acción de correo | «El flujo está activo, así que envía» |
2. La cuenta saliente como punto único de confusión
Muchas instancias tienen varias entradas salientes, cuentas de sistema antiguas y remitentes por usuario. Tras actualizar, a veces funcionan las pruebas de interfaz pero no las credenciales guardadas en segundo plano, por ejemplo tras pasar a contraseñas SMTP más largas o por datos incoherentes. La respuesta sólida no es reescribir la contraseña veinte veces, sino:
- ¿Qué cuenta está prevista para correos del sistema y las tareas?
- ¿Se referencia exactamente esa cuenta en el contexto de la tarea?
- ¿Se ha guardado y verificado de nuevo conscientemente tras actualizar?
- ¿Difieren los errores entre el registro de interfaz y la ventana de tareas?
3. Planificador: el fallo silencioso
Si cron se bloquea en el sistema, las tareas figuran completadas sin efecto o los permisos CLI difieren de los del servidor web, primero fallan recordatorios y correos automáticos, no los manuales. Lista de revisión:
- Crontab o temporizador systemd documentado y asignado al usuario correcto
- Administración → Planificador: tareas críticas activas y última ejecución verosímil
- Tras actualizar: leer e implementar nuevos requisitos, por ejemplo Messenger/Worker según la versión
4. Correos de flujos: lógica antes que SMTP
Antes de culpar al proveedor: ¿el flujo se ejecuta antes de relacionar los contactos? ¿La condición depende de un campo que se completa después en la interfaz? ¿La instancia queda ejecutándose aunque otras acciones funcionen? Son errores de diseño que las pruebas SMTP administrativas no detectan.
5. Orden práctico de diagnóstico
- Reproducir: un registro controlado y un destinatario conocido, con dirección interna.
- Correo de prueba desde la cuenta de sistema prevista.
- Desencadenar el mismo envío por la ruta de tarea o flujo.
- Registros de esa ventana temporal: CRM y MTA/proveedor, si son accesibles.
- Solo después, proveedor, cortafuegos y SPF/DKIM; de otro modo se optimiza la capa equivocada.
SuiteSMTP en AgenticUltimate busca envíos más trazables y mayor visibilidad dentro del CRM. No sustituye cron ni el modelado correcto de flujos. Para equipos con mucho correo automático, la visibilidad suele ser la principal mejora antes de otra reconfiguración SMTP.
SuiteSMTP ↗Conclusión: trate el correo como tres sistemas bajo una misma etiqueta. Quien solo conoce la prueba administrativa no conoce el sistema.