Perfiles, permission sets y licencias Salesforce

El mapa mental correcto

Cuando una pregunta dice que un usuario no puede hacer algo en Salesforce, no corras directo a "dar un permission set". Primero separa el tipo de problema. Tal vez la licencia del usuario ni siquiera permite la funcionalidad. Tal vez el usuario tiene la licencia correcta, pero su perfil base es demasiado limitado. Tal vez le falta permiso de objeto, permiso de campo o permiso de sistema. O tal vez si puede usar el objeto, pero no puede ver ciertos registros porque el modelo de sharing no le abre visibilidad.

El examen suele mezclar esas capas para crear distractores. Una opcion puede sonar razonable porque "da acceso", pero no responde el nivel correcto. Por ejemplo, un permission set puede otorgar acceso a un objeto o a una funcion, pero no cambia el propietario de un registro ni abre automaticamente todos los registros privados de otro usuario. Una sharing rule puede abrir registros, pero no le da a alguien permiso de crear, editar o eliminar si no tiene permisos de objeto.

Regla practica: licencia responde "que producto puede usar"; perfil responde "cual es su base"; permission set responde "que capacidad adicional necesita"; sharing responde "que registros puede ver".

Licencias de usuario y permission set licenses

La licencia de usuario es el marco mas amplio. Determina que funciones de Salesforce pueden estar disponibles para una persona. Si una organizacion compra licencias diferentes, no todos los usuarios tienen el mismo universo de capacidades. Por eso no siempre basta con asignar un permission set: si la licencia no soporta una funcion, Salesforce puede impedir la asignacion o el uso de esos permisos.

Las permission set licenses son una capa relacionada pero diferente. Permiten extender la funcionalidad disponible mas alla de la licencia principal para ciertas capacidades compradas o habilitadas. Aun asi, no sustituyen al permission set. En muchos casos el usuario necesita dos cosas: tener la permission set license correspondiente y tambien tener un permission set que active los permisos especificos de esa funcionalidad.

En preguntas de certificacion, busca palabras como license, available feature, product access, purchased feature o assignment error. Si la pregunta pregunta por una capacidad que no esta incluida en la licencia del usuario, la respuesta suele mencionar licencia o permission set license, no solo perfil. Si la pregunta dice que la capacidad ya esta disponible pero falta autorizar una tarea concreta, entonces permission set vuelve a ser candidato fuerte.

Que debe vivir en perfiles

Cada usuario tiene un solo perfil. El perfil esta asociado a una licencia y establece una base de configuracion. Salesforce recomienda usar perfiles de acceso minimo cuando sea posible y despues agregar permisos mediante permission sets y permission set groups. Este enfoque reduce perfiles inflados, evita duplicacion y facilita mantener el principio de minimo privilegio.

Eso no significa que los perfiles ya no importen. El examen todavia espera que sepas que algunas configuraciones siguen siendo propias o naturales del perfil, como aplicaciones predeterminadas, tipos de registro predeterminados, horas de inicio de sesion, rangos IP y asignacion de page layouts. Si una pregunta habla de default app, login hours, IP ranges o layout assignment por perfil, no la conviertas automaticamente en permission set.

Una trampa frecuente es crear un perfil nuevo para cada rol de negocio. Puede parecer ordenado al inicio, pero se vuelve dificil de mantener. Si tienes vendedores, gerentes y coordinadores que comparten una base parecida pero necesitan tareas distintas, conviene partir de una base minima y agregar bloques reutilizables de permisos. El perfil deberia ser estable; las variaciones de tarea deberian moverse a permission sets.

Como pensar en permission sets

Un permission set es una coleccion de configuraciones y permisos que extiende el acceso funcional de un usuario sin cambiar su perfil. Puede incluir permisos de objeto, permisos de campo, permisos de aplicacion, permisos de sistema, acceso a tabs y otras capacidades. Lo importante es disenarlo por tarea, no por titulo. "Trabajar con leads", "aprobar descuentos" o "administrar Knowledge" son mejores unidades que "Vendedor senior de region norte".

En el examen, permission set suele ser la respuesta cuando se necesita una excepcion pequena o una capacidad adicional para usuarios que ya tienen una base correcta. Si solo dos usuarios necesitan exportar reportes, crear casos o editar un objeto especifico, cambiar el perfil de todos seria demasiado amplio. Un permission set permite otorgar esa capacidad de forma precisa y reversible.

Tambien debes recordar que los permission sets no eliminan acceso que el usuario ya tiene por perfil u otro permission set. Para quitar acceso, revisa la fuente que lo esta otorgando. Si el acceso viene de un permission set asignado, remueve la asignacion o ajusta el set. Si viene de un perfil muy amplio, tal vez el problema real sea migrar a un perfil de menor acceso.

Permission set groups y permisos silenciados

Un permission set group agrupa varios permission sets para representar una persona o funcion de trabajo. En vez de asignar diez permission sets de forma manual a cada nuevo integrante de soporte, puedes agrupar los bloques necesarios y asignar el grupo. Esto mejora consistencia, reduce errores y permite reutilizar permission sets pequenos en mas de una funcion.

Los grupos tambien permiten muting permission sets, que silencian permisos especificos dentro del grupo. Esto es util cuando dos personas comparten casi todo el paquete de permisos, pero una funcion necesita excluir una capacidad puntual. La idea no es construir grupos enormes sin diseno; la idea es componer permisos por tareas y agruparlos segun personas reales de la organizacion.

Para reconocer una pregunta de permission set group, busca frases como job function, persona, bundle, multiple permission sets, easier management o reusable permissions. Si la pregunta pide agrupar varios permisos para un rol completo, el grupo es mejor que asignar sets uno por uno. Si solo hay que agregar una unica capacidad a una persona, un permission set individual puede ser suficiente.

Esta es una de las confusiones mas importantes. Object permissions responden si alguien puede crear, leer, editar o eliminar registros de un objeto. Field-level security responde si puede ver o editar campos. Sharing responde que registros concretos puede ver o editar dentro de ese objeto. Necesitas ambas cosas: permiso para usar el objeto y visibilidad sobre los registros relevantes.

Si Opportunities tiene OWD privado, un usuario puede tener Read y Edit sobre Opportunity y aun asi no ver oportunidades de otro propietario. Darle Modify All en el objeto podria abrir demasiado acceso y romper minimo privilegio. Dependiendo del caso, la respuesta correcta podria ser role hierarchy, sharing rule, manual sharing, team o territory management. En cambio, si el usuario ni siquiera puede crear oportunidades propias, entonces el problema esta antes: permisos de objeto, perfil o permission set.

Para estudiar la visibilidad de registros con mas detalle, lee la guia de OWD, role hierarchy y sharing rules.

Como reconocerlo en preguntas del examen

Lee primero el sintoma y despues la capa. "No puede iniciar sesion a cierta hora" apunta a login hours. "Necesita usar una funcion adicional no incluida" apunta a licencia o permission set license. "Necesita crear registros de un objeto" apunta a object permission. "Necesita ver un campo" apunta a field-level security. "Necesita ver registros de otros usuarios" apunta a sharing. "Un grupo de usuarios con la misma funcion necesita varios permisos" apunta a permission set group.

Despues evalua el alcance. Si la solucion afecta a muchos usuarios que comparten perfil, cuidado: tal vez sea demasiado amplia. Si solo afecta a una excepcion o tarea especifica, permission set suele ser mas seguro. Si la pregunta pide simplificar administracion para nuevas contrataciones o funciones repetibles, permission set group gana fuerza. Si menciona minimo privilegio, evita respuestas que den View All Data, Modify All Data o perfiles muy poderosos sin necesidad.

Checklist de decision rapida:

La funcion existe para la licencia del usuario?
El problema es permiso de objeto, campo, sistema o app?
El usuario necesita acceso funcional o visibilidad de registros?
Es una excepcion individual, una tarea repetible o una persona completa?
La respuesta respeta minimo privilegio?

Recursos oficiales y practica

Para estudiar este tema, combina documentacion oficial con practica de escenarios. Primero entiende las definiciones; despues resuelve preguntas preguntandote que capa esta fallando. Si fallas una pregunta, no memorices la opcion. Escribe la regla que confundiste: "permission set no abre registros privados", "profile no debe multiplicarse por cada titulo", "permission set license no reemplaza al permission set".

BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.