5 revisiones de salud de Salesforce que todo administrador debería hacer
La mayoría de las orgs de Salesforce acumulan deuda técnica en silencio. Aquí hay cinco verificaciones que sacan a la luz los problemas reales antes de que se conviertan en incidentes.
La mayoría de las orgs de Salesforce no fallan de forma dramática — se degradan silenciosamente. Un flujo que funcionaba bien con 500 registros empieza a agotar límites con 50 000. Un conjunto de permisos que tenía sentido hace dos años ahora otorga accesos que no debería. Una automatización que nadie recuerda haber escrito se ejecuta en cada actualización y ralentiza la carga de páginas.
Estas cinco verificaciones llevan una tarde. Sacan a la luz los problemas que cuestan tiempo y confianza a tu equipo en silencio.
1. Auditoría de exposición a límites de gobernador
Revisa tus registros de ejecución de Apex en Configuración → Trabajos de Apex y busca cualquier cosa que use regularmente más del 50 % de los límites de CPU o SOQL. No son fallos todavía — pero están a una carga de datos de serlo.
Qué buscar:
- Automatizaciones activadas en objetos de alto volumen (casos, pedidos, registros de log)
- Consultas SOQL dentro de bucles (el error clásico — una consulta por registro en vez de una para todos)
- Llamadas síncronas bloqueando la transacción
Ganancia rápida: Activa los registros de depuración en tu usuario de integración durante una hora ocupada y busca advertencias de Maximum CPU time. Si las ves, tienes un temporizador en marcha.
2. Revisión del modelo de seguridad
El modelo de seguridad de Salesforce es potente, pero es fácil conceder demasiado. Ejecuta el Analizador de conjuntos de permisos (disponible en el Centro de Seguridad si lo tienes, o manualmente via SOQL) y comprueba:
- Cualquier perfil o conjunto de permisos con “Modificar todos los datos” o “Ver todos los datos” que no sea un usuario de integración del sistema
- Usuarios con acceso de edición a campos que solo necesitan leer
- Grupos públicos con acceso a tipos de registros sensibles
Una consulta SOQL rápida para ejecutar en la Consola del desarrollador:
SELECT Name, PermissionsModifyAllData, PermissionsViewAllData
FROM PermissionSet
WHERE PermissionsModifyAllData = true OR PermissionsViewAllData = true
Si aparecen usuarios que no son de integración, investiga. El mínimo privilegio no es solo una buena práctica — es tu defensa en una auditoría.
3. Inventario de automatizaciones inactivas
Toda org de Salesforce tiene automatizaciones que fueron “temporalmente” desactivadas y luego olvidadas. No causan daño estando ahí, pero crean confusión — y a veces se reactivan accidentalmente durante los despliegues.
Ejecuta esto en la Consola del desarrollador:
SELECT DeveloperName, ProcessType, Status, LastModifiedDate
FROM Flow
WHERE Status = 'Obsolete' OR Status = 'InvalidDraft'
ORDER BY LastModifiedDate ASC
Elimina lo que esté verdaderamente muerto. Para cualquier cosa de la que no estés seguro: añade una descripción, anota quién es el responsable y establece una fecha de revisión. Las automatizaciones no documentadas son un ticket de soporte en espera.
4. Verificación rápida de calidad de datos
Los malos datos son el asesino silencioso del ROI de Salesforce. Una auditoría rápida por muestra:
- Leads sin email ni teléfono — ¿para qué sirve ese registro?
- Cuentas sin contactos asociados — registros huérfanos de importaciones
- Oportunidades estancadas en la misma etapa durante más de 90 días — ilusión de pipeline
- Tasa de detección de duplicados — ejecuta el informe de Trabajos de duplicados y ve qué porcentaje de los nuevos registros son marcados
No necesitas arreglarlo todo hoy. Pero conocer la forma de tu problema de calidad de datos te dice dónde invertir en reglas de validación, coincidencia de duplicados o un proyecto de limpieza.
5. Gestión de versiones y seguimiento de cambios
Este es procedimental, no técnico — pero es el que la mayoría de las orgs omite. Pregúntate:
- ¿Tienes un registro de cambios (incluso una simple hoja de cálculo) de lo que se desplegó en los últimos 6 meses?
- ¿Tus flujos y clases de Apex se despliegan via CI/CD o conjuntos de cambios — o ediciones directas en producción?
- Cuando algo falla, ¿puedes identificar en menos de 10 minutos qué cambió y quién lo cambió?
Si la respuesta a alguna de estas es “no”, estás operando sin red de seguridad. El primer paso es simplemente exigir que todo cambio en producción pase primero por un sandbox, con un ticket o mensaje de Slack indicando qué se hizo y por qué.
Convertirlo en una rutina
Ninguna de estas verificaciones es para hacerla una sola vez. Las orgs que se mantienen sanas son aquellas donde alguien repasa esta lista (o una versión de ella) trimestralmente. Ponla en tu calendario. Comparte los resultados con los interesados. Es la diferencia entre gestionar tu org y ser gestionado por ella.
¿Necesitas una revisión profesional de tu org? Ofrecemos auditorías de Salesforce estructuradas — contáctanos para saber qué hay en la tuya.