La pregunta fundamental: ¿Qué determina el acceso de un usuario?
Cuando alguien pregunta "¿cómo obtuvo un usuario acceso a este campo?", la respuesta correcta es casi siempre una combinación: su Profile determina el acceso base, los Permission Set Groups asignados añaden capacidades según la función, y a veces un Permission Set individual gestiona una excepción específica. El problema en la práctica es que la mayoría de las organizaciones construyen esta combinación en la dirección opuesta, comenzando con un Profile amplio que contiene casi todo, y luego "solucionando" problemas puntuales con permisos individuales que nadie recuerda eliminar.
Un modelo de permisos saludable se construye en la dirección opuesta: un Profile lo más restringido posible, que defina principalmente la licencia, el acceso predeterminado a las aplicaciones y las características de inicio de sesión; y toda capacidad de trabajo real –qué objetos, qué campos, qué acciones– se traslada a los Permission Sets y Permission Set Groups. Es importante aclarar: este artículo aborda únicamente el nivel de Object, Field y System Permissions. Las cuestiones de visibilidad de los registros entre usuarios (OWD, Role Hierarchy, Sharing Rules) se discuten en la Guía de Visibilidad y Compartición, ya que se trata de una capa de decisión separada con sus propias compensaciones (trade-offs).
Las tres unidades y su función
| Unidad | Qué determina | Cuántas puede tener un usuario | Cuándo se elige |
|---|---|---|---|
| Profile | Licencia, App Visibility predeterminada, Page Layout, Login Hours/IP | Exactamente uno | Diferencias de infraestructura entre tipos de usuarios |
| Permission Set | Permisos de Objeto, Campo, Apex Class, Pestaña (Tab) - solo añade | Tantos como sea necesario | Una única capacidad relevante para algunas funciones |
| Permission Set Group | Agrupación de varios Permission Sets bajo un nombre, con opción de Muting | Tantos como sea necesario | Una combinación fija de permisos que representa un rol de trabajo completo |
La diferencia entre un Permission Set y un Permission Set Group no es solo técnica, es organizacional. Un Permission Set individual es adecuado para una capacidad única y específica ("acceso a informes financieros"). Un Permission Set Group es adecuado cuando se quiere asignar un "paquete de trabajo" completo a un departamento o a una función, y mantenerlo en un solo lugar cuando cambie.
Marco de decisión: ¿Dónde pertenece un nuevo permiso?
Cuando surge una solicitud para añadir acceso, la primera pregunta no es "¿a qué Profile añadir?" sino a qué unidad pertenece el permiso desde una perspectiva estructural:
- ¿Es un permiso que caracteriza a todos los que tienen el mismo tipo de licencia? Si es así, es un lugar para el Profile, siempre que se refiera a todos los titulares de la licencia y no a un subconjunto.
- ¿Es una capacidad de trabajo que un grupo de rol específico siempre necesita junto con permisos adicionales? Si es así, es un lugar para el Permission Set Group, incluso si primero hay que dividirlo en varios Permission Sets separados para permitir una combinación flexible.
- ¿Es un permiso puntual y temporal para un usuario individual o una excepción? Si es así, un Permission Set independiente, asignado manualmente y revisado en la auditoría periódica.
- ¿Debe el permiso negar algo a un usuario específico dentro de un grupo amplio? Aquí entra un Muting Permission Set dentro de un Permission Set Group, la única herramienta en Salesforce que permite reducir un permiso sin tocar el Profile o desagrupar el grupo.
La regla que previene la mayor parte de la "deriva": nunca se edita un Profile para resolver un problema de un solo usuario. Si la corrección se define como una excepción, pasa por un Permission Set documentado y con fecha de revisión.
Lista de verificación para construir un modelo de permisos desde cero
- ☐ Se han mapeado las funciones de trabajo reales (no los departamentos organizacionales) y cada función ha recibido un nombre claro.
- ☐ Para cada función, se ha definido una lista de capacidades requeridas a nivel de objeto, campo y Apex Class.
- ☐ Se han construido Permission Sets enfocados en una única capacidad, no "pilas de permisos" genéricas.
- ☐ Cada función ha recibido un único Permission Set Group que agrupa las capacidades relevantes.
- ☐ Los Profiles se han reducido a meras diferencias de licencia e infraestructura.
- ☐ Se ha definido un proceso para casos excepcionales: quién aprueba un Permission Set puntual y por cuánto tiempo.
- ☐ Se ha establecido una frecuencia de auditoría (trimestral al menos) que compara los permisos activos con la función actual.
- ☐ Se ha definido un único propietario para el mantenimiento del modelo de permisos frente a los cambios en la estructura organizacional.
Escenario organizacional: Una compañía de seguros con tres unidades de ventas
Consideremos una compañía de seguros mediana con unos trescientos usuarios de Salesforce, divididos en tres unidades: ventas directas, ventas a través de agentes y reclamaciones. Antes del proyecto, la compañía tenía doce Profiles diferentes, algunos de ellos copias casi idénticas creadas para "corregir" un permiso para un grupo pequeño. Resultado típico: cuando un nuevo agente se incorporaba, nadie sabía con certeza cuál de los doce Profiles era el adecuado para él, y la respuesta en la práctica era "copie de alguien similar".
El equipo de arquitectos reconstruyó el modelo: solo tres Profiles, según el tipo de licencia (Sales Cloud completo, Community para agentes externos, Service Cloud para reclamaciones). Sobre ellos, siete Permission Set Groups según la función de trabajo real: representante de ventas, gerente de equipo de ventas, agente externo, gerente de agentes, evaluador de reclamaciones, gerente de reclamaciones, y un rol de puente que maneja tanto ventas como reclamaciones. Cada Permission Set Group se compuso de Permission Sets específicos como "acceso a pólizas activas" o "aprobación de reembolso hasta un límite definido", de modo que pudieran combinarse de nuevo al surgir un nuevo rol sin construir el permiso desde cero.
El resultado medible: el tiempo de configuración de un nuevo usuario se redujo de varios días (que incluían la verificación manual de qué Profile era el adecuado) a unas pocas horas, y el número de solicitudes de soporte del tipo "no tengo acceso al campo X" se redujo a la mitad en el trimestre posterior a la transición, ya que la mayoría de estas solicitudes se debían a un Profile que no incluía la capacidad y no estaba claro a quién recurrir para la corrección.
Riesgos comunes y acciones de prevención
| Riesgo | Cómo se ve en la práctica | Acción de prevención |
|---|---|---|
| El Profile se convierte en una herramienta de corrección puntual | Multiplexidad de Profiles casi idénticos, cada uno para un grupo pequeño | Trasladar cada permiso puntual a un Permission Set y reducir los Profiles solo a la licencia |
| Seguridad a nivel de campo (FLS) inconsistente | El mismo campo está expuesto en un lugar y bloqueado en uno paralelo | Documentar una matriz de FLS central para cada campo sensible y revisarla en cada Release |
| Los permisos "se mantienen adheridos" después de un cambio de función | Un usuario que cambió de función mantiene los permisos del rol anterior | Un proceso de Offboarding de función que elimina el Permission Set Group antiguo antes de añadir uno nuevo |
| Permisos de sistema demasiado amplios (View All Data, Modify All) | Se otorgan "para ahorrar tiempo" y no se eliminan después | Aprobación específica y fecha de vencimiento para cada permiso de sistema amplio |
| Ausencia de un propietario para el modelo de permisos | Cada equipo añade permisos sin una visión integral | Un único propietario que aprueba cada nuevo Permission Set o Group antes de la implementación |
Métricas para evaluar la salud del modelo
| Área | Qué se mide | Frecuencia de revisión |
|---|---|---|
| Redundancia innecesaria | Número de Profiles activos en relación con el número de tipos de licencia reales | Trimestral |
| Precisión del permiso | Porcentaje de usuarios cuyos permisos coinciden con el rol registrado en RR.HH. | Trimestral |
| Excepciones abiertas | Número de Permission Sets puntuales sin fecha de revisión | Mensual |
| Permisos amplios | Número de usuarios con View All Data / Modify All Data sin justificación documentada | Mensual |
| Tiempo de configuración | Tiempo promedio desde la solicitud de nuevo acceso hasta la asignación completa | Continuo |
En una primera versión de seguimiento, conviene limitarse a tres métricas de las cinco y ampliarlas solo después de tener una línea de base fiable. Una métrica que no tiene propietario ni fecha de revisión tiende a desaparecer del informe después del primer mes.
Cómo se integra esto en la arquitectura más amplia
Un buen modelo de permisos es una condición previa, no un sustituto, para la planificación de la visibilidad de los registros (OWD, Role Hierarchy, Sharing Rules); ambos temas se complementan pero se resuelven por separado. Una organización que intenta resolver un problema de visibilidad ampliando un Profile, o viceversa, suele descubrir que la solución es frágil en cuanto cambia la estructura organizativa. Cuando la organización transita entre múltiples Orgs y un solo Org, el modelo de permisos es una de las cosas que deben remapearse; se encuentra una ampliación sobre el tema en la Guía Single Org frente a Multi Org. Y cuando el permiso en sí depende de una lógica condicional compleja, conviene examinar si la implementación pertenece a Flow o a Apex, como se detalla en la Guía Flow frente a Apex.
En organizaciones que ejecutan procesos basados en eventos entre sistemas, es crucial asegurarse de que los permisos de los usuarios de integración (Integration Users) se construyan bajo el mismo principio: Permission Sets específicos y no un Profile amplio con "System Administrator" como predeterminado de conveniencia. Este tema se conecta con la planificación más amplia de la comunicación entre sistemas, descrita en la Guía de Arquitectura Orientada a Eventos para Salesforce.
Resumen
Un modelo de permisos que resiste la prueba del tiempo se construye de abajo hacia arriba: capacidades específicas en Permission Sets, su ensamblaje según el rol de trabajo real en Permission Set Groups, y un Profile que mantiene un rol mínimo de licencia e infraestructura solamente. La señal clara de un fallo es la proliferación de Profiles creados para resolver problemas puntuales; cada Profile adicional de este tipo es una deuda que se acumula hasta que nadie recuerda por qué existe. Cuando falta la capacidad interna para construir o limpiar un modelo existente, el servicio de arquitectura de CRM ofrece una ruta práctica para un inicio enfocado.