Perfiles vs permission sets vs sharing rules en Salesforce
Perfiles y permission sets controlan el acceso a objetos y campos; las sharing rules, a qué registros. La doble comprobación decide qué puede hacer cada usuario.
“Profiles vs permission sets vs sharing rules” confunde a mucha gente porque las tres no son alternativas: responden a preguntas distintas y trabajan juntas. Los perfiles y los permission sets deciden qué puedes hacer con un objeto; las sharing rules deciden sobre qué registros puedes hacerlo. Así es como se combinan.
El modelo de doble comprobación
Cada acceso a un registro en Salesforce pasa dos comprobaciones independientes:
- Comprobación de objeto y campo — desde perfiles y permission sets: ¿tiene el usuario CRUD sobre el objeto y seguridad a nivel de campo sobre los campos?
- Comprobación de registro — desde el modelo de colaboración: ¿conceden este registro concreto los valores predeterminados de la organización (OWD), la jerarquía de roles o una sharing rule?
El permiso de objeto es la puerta. La colaboración decide qué registros la atraviesan. Ambas deben pasar.
Esta es la base de todo el modelo de acceso a registros.
Perfiles y permission sets: el “qué puedes hacer”
Estos controlan el acceso a nivel de objeto y más:
- CRUD por objeto (Read / Create / Edit / Delete).
- Seguridad a nivel de campo — qué campos son visibles/editables.
- Permisos del sistema, visibilidad de aplicaciones y pestañas, y los View All / Modify All, que saltan el acceso.
Perfil vs permission set
- Un usuario tiene exactamente un perfil — históricamente la línea base de permisos.
- Un usuario puede tener muchos permission sets (y permission set groups) superpuestos.
El enfoque moderno y recomendado se basa en los permission sets: mantén el perfil al mínimo y concede el acceso mediante permission sets, porque son más fáciles de asignar, reutilizar y auditar que una maraña de perfiles. (Los roles, en cambio, gobiernan la jerarquía de colaboración: un eje distinto al de los perfiles).
Sharing rules: el “qué registros”
Las sharing rules no tocan en absoluto el acceso a objeto ni a campo. Solo amplían el acceso a nivel de registro —por propiedad o por criterios— sobre el valor predeterminado de la organización. Para ver cómo se relacionan con la jerarquía, consulta sharing rules vs jerarquía de roles.
Y lo más importante: una sharing rule no puede rescatar un permiso de objeto que falta. Sin Read sobre Opportunities no hay oportunidades, por muchas sharing rules que apunten al usuario.
Dónde los permisos anulan la colaboración
Hay un punto donde las capas se cruzan: View All y Modify All (a nivel de objeto) y View All Data / Modify All Data (a nivel de todo el sistema). Estos saltan por completo el modelo de colaboración: un usuario que los tenga ve todos los registros sin importar OWD, jerarquía ni reglas. Como son tan potentes, son lo primero que hay que revisar cuando el acceso parece incorrecto. Consulta View All / Modify All — el atajo que hay que vigilar.
Juntándolo todo
| Pregunta | Respondida por |
|---|---|
| ¿Puede el usuario abrir siquiera este objeto? | Perfil / permission set (CRUD) |
| ¿Puede ver este campo? | Seguridad a nivel de campo |
| ¿Qué registros del objeto puede ver? | Modelo de colaboración |
| ¿Puede saltarse la colaboración? | View All / Modify All |
Para entender por qué un usuario puede o no llegar a un registro, hay que leer ambos ejes juntos: los permisos de objeto/campo y la colaboración que aplica a ese registro.
Leer ambos ejes a la vez
La fricción está en que estos viven en partes distintas de la configuración —perfiles y permission sets en un sitio, el modelo de colaboración en otro— y tienes que cruzarlos mentalmente. AgentForceAccess hace esa intersección por ti: pregunta qué puede hacer un usuario con un registro y tiene en cuenta los permisos de objeto, la seguridad a nivel de campo y el modelo de colaboración a la vez, citando exactamente qué concede o bloquea el acceso.
Preguntas frecuentes
¿Cuál es la diferencia entre acceso a objeto y acceso a registro?
El acceso a objeto (de perfiles y permission sets) decide si un usuario puede tocar siquiera un objeto —Read, Create, Edit, Delete— y qué campos ve. El acceso a registro (el modelo de colaboración) decide qué registros concretos de ese objeto puede ver. Necesitas ambos.
¿Perfiles o permission sets: cuál debo usar?
Existen ambos, pero el enfoque moderno se basa en los permission sets: mantén los perfiles al mínimo como línea base y concede el acceso adicional mediante permission sets y permission set groups. Un usuario tiene un perfil, pero puede tener muchos permission sets, lo que facilita asignar y auditar el acceso.
¿Las sharing rules conceden acceso a objeto?
No. Las sharing rules solo amplían el acceso a nivel de registro. Si un usuario no tiene permiso Read sobre un objeto a través de su perfil o un permission set, ninguna sharing rule le mostrará ni un solo registro. El permiso de objeto es la puerta; la colaboración decide qué registros la atraviesan.
¿Cómo puede un perfil anular una sharing rule?
Mediante View All y Modify All. Estos permisos —a nivel de objeto, o "View All Data"/"Modify All Data" a nivel de todo el sistema— permiten a un usuario ver o editar todos los registros sin importar la colaboración. Se sitúan por encima del modelo de colaboración, así que un permiso puede anular lo que la colaboración restringiría.
Míralo en tu propia organización
AgentForceAccess explica, en lenguaje claro, por qué cualquier usuario puede ver cualquier registro o archivo, recorriendo todos los mecanismos de colaboración de Salesforce.
Solicitar acceso anticipado