Cómo diseñar un modelo de permisos escalable en Salesforce

Un modelo de permisos de Salesforce empieza siendo simple. Un perfil para los representantes de ventas, uno para los gestores, uno para los administradores. Luego la empresa crece, los roles se multiplican, ocurren adquisiciones, se añaden productos — y de repente tienes 47 perfiles, nadie sabe qué hace ninguno de ellos, y cambiar un permiso de campo lleva tres horas de pruebas porque no estás seguro de quién se verá afectado.

Esto no tiene por qué pasar. Así se construye un modelo de permisos que se mantiene manejable a medida que la org crece.

Entiende las herramientas antes de elegirlas

Salesforce te da varias capas:

Herramienta	Controla	Mejor uso
Perfil	CRUD de objeto/campo, visibilidad de apps, horas/IP de inicio de sesión	Solo acceso base — el mínimo que necesita cada usuario de ese tipo
Conjunto de permisos	Igual que el perfil, solo aditivo	Adiciones específicas de funcionalidad o rol sobre el perfil
Grupo de conjuntos de permisos	Agrupa múltiples conjuntos de permisos	Asignar un “paquete de rol” completo a un tipo de usuario
Conjunto de permisos silenciador	Elimina permisos dentro de un GCP	Manejar excepciones dentro de un grupo

La clave: los perfiles deben ser mínimos, los conjuntos de permisos hacen el trabajo real.

El enfoque de “perfil mínimo viable”

Las orgs más mantenibles que hemos visto usan 3 a 5 perfiles:

1. Usuario estándar — lectura/creación básica en objetos principales, sin campos sensibles, sin operaciones destructivas
2. Usuario avanzado — edición y eliminación en la mayoría de objetos, visibilidad moderada de campos
3. Solo lectura — para contratistas, auditores, integraciones que solo necesitan leer
4. Administrador del sistema — acceso completo, solo para administradores reales
5. (Opcional) Usuario de comunidad / portal — para Experience Cloud

Eso es todo. Cada variación en el acceso — un gestor de ventas que puede ver campos de ingresos, un agente de soporte que puede cerrar casos, un usuario de marketing que solo accede a campañas — se maneja con conjuntos de permisos apilados sobre el perfil base.

Esto significa que puedes cambiar un perfil y saber exactamente quién se ve afectado. Significa que incorporar a un nuevo usuario es asignar un perfil y algunos conjuntos de permisos, no clonar un perfil a medida y ajustar manualmente 200 configuraciones.

Nombrar conjuntos de permisos que puedas encontrar

Tres meses después de crearlos, los conjuntos de permisos se vuelven imposibles de encontrar si se llaman CP_RepVentas_V2_NUEVO o Acceso completo marketing. Usa una convención de nomenclatura consistente:

[Objeto/Funcionalidad] — [Acción/Nivel]

Ejemplos:

• Oportunidad — Editar campos de ingresos
• Caso — Cerrar y eliminar
• Informes — Crear y editar
• CPQ — Acceso completo

Cuando buscas en tu lista de conjuntos de permisos todo lo relacionado con Casos, cada conjunto relevante aparece junto. Cuando miras los conjuntos asignados a un usuario, puedes leer qué hace cada uno sin abrirlo.

Grupos de conjuntos de permisos: el enfoque de “paquete de rol”

Si un tipo de usuario necesita consistentemente 6 a 8 conjuntos de permisos, agrúpalos en un Grupo de conjuntos de permisos. En lugar de asignar cada conjunto individualmente, asignas un solo grupo.

Un gestor de servicios de campo podría necesitar:

• Orden de trabajo — Editar y cerrar
• Activo — Ver y crear
• Cita de servicio — Acceso completo
• Informes — Crear y editar
• App móvil — Acceso completo

Agrúpalos en un grupo llamado Gestor de servicios de campo y asigna esa única cosa. Si las necesidades del gestor cambian, actualizas el grupo — y cada gestor recibe el cambio automáticamente.

Los permisos peligrosos a vigilar

Algunos permisos son fáciles de conceder en exceso y difíciles de auditar. Revísalos regularmente:

Ver todos los datos / Modificar todos los datos — estos permisos sortean completamente las reglas de uso compartido. Solo los usuarios de integración y los administradores del sistema deberían tenerlos. Ejecuta este SOQL trimestralmente:

SELECT Name, PermissionsViewAllData, PermissionsModifyAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true OR PermissionsModifyAllData = true

Gestionar usuarios — permite a alguien crear usuarios, asignar conjuntos de permisos, restablecer contraseñas. En las manos equivocadas, es una ruta de escalada de privilegios.

API habilitada — necesaria para integraciones y desarrolladores, pero no debería estar en cada perfil de usuario final. Es un vector común en incidentes de exfiltración de datos.

Crear Apex / Personalizar aplicación — estos permisos permiten a los usuarios cambiar los metadatos de la org. A menos que alguien sea realmente un administrador o desarrollador, no lo necesita.

Seguridad a nivel de campo: la capa olvidada

El acceso a objetos es la parte en la que todos piensan. El acceso a campos es la parte que te sorprende.

Un usuario con acceso de visualización a Oportunidades aún puede ver todos los campos a menos que la SNC (Seguridad a nivel de campo) los restrinja. Para campos sensibles — ingresos, márgenes, datos personales, números de seguridad social — establece la SNC explícitamente en cada perfil y conjunto de permisos, no asumas que estarán ocultos por defecto.

Cuando añades un nuevo campo a cualquier objeto, pregúntate: ¿quién realmente necesita ver esto? Ajusta la SNC antes de que el campo entre en servicio, no después de que alguien lo note en un informe.

Documentar el modelo

Mantén como mínimo una hoja de cálculo simple o una página de Confluence con:

• Cada perfil: el tipo de usuario para el que está destinado, qué lo diferencia de los demás
• Cada grupo de conjuntos de permisos: qué roles de usuario lo usan
• Cada conjunto de permisos independiente: qué otorga y con qué perfiles suele combinarse

Este documento es tu guía de incorporación, tu evidencia de auditoría y tu punto de partida para la resolución de problemas cuando un usuario se queja de no poder ver un campo que debería ver.

Migrar desde perfiles complejos

Si tu org ha proliferado a más de 30 perfiles, no tienes que arreglarlo todo de una vez. Un enfoque práctico:

1. Congelar la creación de perfiles — no más perfiles sin aprobación
2. Para nuevos tipos de usuarios, usar conjuntos de permisos desde el primer día
3. Identificar los 3 a 4 perfiles más usados y dejarlos por ahora
4. Cuando tengas una razón para tocar un perfil (un nuevo campo, un nuevo objeto), tómate 20 minutos para evaluar si ese perfil puede consolidarse en uno estándar

En 12 a 18 meses, el número baja naturalmente sin una migración arriesgada de una sola vez.

---

¿Tu modelo de permisos está esperando una revisión? Ofrecemos auditorías de seguridad de Salesforce estructuradas. Contáctanos para saber dónde estás.