El mejor modelo de uso compartido de Salesforce empieza cerrado y abre el acceso a propósito. Fije los valores predeterminados de toda la org (OWD) en el nivel más restrictivo con el que sus usuarios puedan trabajar, y luego use la jerarquía de roles y las reglas de uso compartido de Salesforce para otorgar acceso adicional solo donde haya una razón de negocio. Las reglas de uso compartido solo pueden ampliar el acceso, nunca reducirlo, así que el orden en que construye importa.
Esta guía recorre cada capa, las prácticas que mantienen una org fácil de entender y los errores que causan tanto el exceso de acceso como los tickets de "no puedo ver a mi cliente". Los detalles se verificaron en la documentación de Salesforce en noviembre de 2026.
Las cuatro capas de acceso
La guía de arquitectura de Salesforce indica que el acceso se aplica a través de cuatro capas: organización, objeto, campo y registro (Salesforce Architects, Trust, consultado en noviembre de 2026).
- Organización: restricciones de inicio de sesión y qué funciones están activas.
- Objeto: si un usuario puede crear, leer, editar o eliminar un tipo de registro.
- Campo: qué campos de ese objeto son visibles o editables.
- Registro: qué registros específicos puede ver el usuario.
El modelo de uso compartido controla la cuarta capa. Los perfiles y los conjuntos de permisos controlan las tres primeras. Un error común es intentar resolver un problema de acceso a registros con permisos de objeto, o al revés. Nuestro artículo sobre conjuntos de permisos vs. perfiles cubre la otra mitad.
Empiece con los valores predeterminados de toda la org
Los valores predeterminados de toda la org (OWD) fijan el acceso base que tienen los usuarios a los registros que no les pertenecen. La guía de uso compartido de la plataforma de Salesforce dice que se debe empezar de forma restrictiva y abrir el acceso de manera selectiva con otras herramientas (Salesforce Architects, Platform Sharing Architecture, consultado en noviembre de 2026).
Una regla práctica: fije el OWD de cada objeto en el acceso que debería tener su usuario más restringido. Para los objetos que contienen información sensible de clientes, eso suele ser Private. Para los datos de referencia que todos necesitan, como una lista de programas, Public Read Only puede estar bien.
Dos precauciones:
- Cambiar el OWD activa un recálculo del uso compartido, que puede tardar mucho con grandes volúmenes de datos. Planifique los cambios para un periodo de poca actividad y pruebe primero en un sandbox.
- No afloje el OWD para resolver el problema de una sola persona. Use una regla de uso compartido o un equipo para la excepción.
Use la jerarquía de roles con cuidado
La jerarquía de roles permite que los gerentes vean los registros que pertenecen a las personas que están debajo de ellos. Salesforce indica que asegura que los gerentes tengan acceso a los mismos datos que sus empleados, sin importar la configuración del OWD.
Mejores prácticas:
- Modele los roles según el acceso a los datos, no según el organigrama. Salesforce aconseja construir cada rol en torno a un nivel de acceso a los datos. Un rol existe para dar visibilidad, no para reflejar los cargos.
- Manténgala poco profunda. Salesforce sugiere no más de 10 niveles de ramas.
- Recuerde que los pares no se ven entre sí. Dos personas en el mismo rol no ven automáticamente los registros de la otra.
- Revise la configuración "Grant Access Using Hierarchies" en los objetos personalizados. Está activada por defecto. Desactivarla impide que los usuarios más altos en la jerarquía hereden el acceso, lo que puede ser útil en un objeto sensible donde los gerentes no necesitan verlo todo.
Reglas de uso compartido: la herramienta para las excepciones
Las reglas de uso compartido dan a usuarios adicionales acceso a registros que no les pertenecen, y se aplican cuando el OWD es Private o Public Read Only (Salesforce Help, Sharing and Record Access Features, consultado en noviembre de 2026). Hay dos tipos principales:
- Reglas basadas en el propietario comparten registros según quién es su propietario. Ejemplo: compartir los registros que pertenecen al equipo de admisión con el equipo de coordinación de cuidados.
- Reglas basadas en criterios comparten registros según los valores de los campos, sin importar el propietario. Ejemplo: compartir los registros donde Program es igual a cierto programa con el grupo de personal de ese programa.
Buenos hábitos:
- Comparta con grupos públicos o roles, no con individuos. Cuando alguien cambia de equipo, usted cambia el grupo, no veinte reglas.
- Dé a las reglas nombres y descripciones claros que indiquen la razón de negocio. Usted en el futuro lo agradecerá.
- Prefiera el acceso de lectura a menos que el grupo realmente edite los registros.
- Vigile los límites. Salesforce indica 300 reglas de uso compartido basadas en el propietario por objeto y 50 reglas basadas en criterios y de usuario invitado combinadas por objeto. Si está cerca, probablemente hay que replantear el diseño.
- Tenga especial cuidado con las reglas de uso compartido para usuarios invitados. Salesforce señala que otorgan acceso amplio a usuarios no autenticados y conllevan un riesgo significativo de exposición.
Otras herramientas que conviene conocer
- Uso compartido manual: los propietarios de registros o los administradores pueden compartir un solo registro. Es útil para casos aislados, pero desaparece cuando cambia el propietario, así que no construya un proceso sobre él.
- Equipos: los equipos de cuenta, oportunidad y caso dan acceso a un grupo a un solo registro. Salesforce señala que hay un solo equipo por registro.
- Reglas de restricción: a diferencia de las reglas de uso compartido, estas reducen el acceso. Salesforce indica que se aplican a objetos personalizados, objetos externos, contratos, eventos, tareas, hojas de tiempo y entradas de hojas de tiempo, con límites según la edición. Pueden ayudar cuando un grupo debe ver solo un subconjunto de registros.
- Apex managed sharing: para los casos en que las herramientas declarativas no pueden cumplir el requisito, o cuando un sistema externo es la fuente de verdad del acceso.
- Permisos que omiten el uso compartido: Salesforce señala que View All y Modify All se saltan las reglas y configuraciones de uso compartido, y recomienda las versiones a nivel de objeto en lugar de View All Data y Modify All Data a nivel de toda la org. Revise quién los tiene. Nuestro artículo sobre cómo encontrar usuarios con permisos excesivos muestra cómo.
Cuidado con las trampas de rendimiento
La guía de Salesforce señala dos problemas para las orgs más grandes:
- Data skew: cuando un registro padre tiene una cantidad muy grande de registros hijos, el rendimiento puede degradarse. Salesforce menciona una proporción de alrededor de 1 a 10,000 como un punto que se debe evitar.
- Ownership skew: cuando un usuario es propietario de una cantidad muy grande de registros, Salesforce aconseja mantener a ese usuario fuera de la jerarquía de roles o colocar su rol en la parte superior, en su propia rama. Una causa común es un usuario genérico de "integración" o "admin" que es propietario de todo.
Evite también los cambios estructurales frecuentes. Salesforce sugiere hacer cambios en la jerarquía no más de una vez por trimestre, planificados y probados en un sandbox.
Errores comunes que vemos
- Fijar el OWD en Public Read/Write "para que paren las quejas".
- Decenas de reglas de uso compartido aisladas que nadie puede explicar.
- Una jerarquía de roles profunda copiada de un organigrama.
- Otorgar View All o Modify All a todo un equipo por comodidad.
- Ningún registro escrito de por qué existe cada regla.
Cómo diagnosticar "no puedo ver este registro"
La guía de Salesforce da un orden que funciona bien:
- ¿El usuario tiene permiso sobre el objeto?
- ¿Cómo se compara el rol del usuario con el rol del propietario?
- ¿Están en ramas distintas de la jerarquía?
- ¿Hay una regla de uso compartido, y el usuario está en el grupo público correcto?
- ¿Se usa un equipo, y el usuario forma parte de él?
- ¿Se perdió un uso compartido manual cuando cambió la propiedad?
Trabaje de arriba hacia abajo y encontrará la mayoría de los problemas en pocos minutos.
Documéntelo
Un modelo de uso compartido que nadie puede explicar es difícil de defender en una auditoría. Anote, para cada objeto sensible: el OWD, quién puede ver qué y por qué, y qué reglas existen. El producto Security Framework Design de Troppus ofrece plantillas de gobernanza para roles, perfiles y reglas de uso compartido con documentación lista para auditoría, y nuestro Apex Security Check busca permisos excesivos. Puede ver ambos en la página de productos.
Preguntas frecuentes
¿Cuál es la diferencia entre una regla de uso compartido y un conjunto de permisos?
Un conjunto de permisos controla lo que un usuario puede hacer con un objeto y sus campos. Una regla de uso compartido controla qué registros puede ver el usuario. Normalmente necesita ambos.
¿Una regla de uso compartido puede hacer el acceso más restrictivo?
No. Las reglas de uso compartido solo otorgan acceso adicional más allá del OWD y la jerarquía de roles. Para reducir el acceso, baje el OWD o use reglas de restricción donde estén disponibles.
¿Todos los objetos deben ser Private?
No necesariamente. Use la configuración más restrictiva con la que sus usuarios puedan trabajar. Los objetos que contienen información sensible de clientes o de salud suelen ser Private. Los datos de referencia compartidos pueden ser más abiertos.
¿Cuántas reglas de uso compartido son demasiadas?
Salesforce fija límites por objeto, pero mucho antes de llegar a ellos, una gran cantidad de reglas se vuelve difícil de mantener. Si no puede explicar cada regla en una frase, consolide.
¿El modelo de uso compartido importa para HIPAA o para las auditorías de financiadores?
Es uno de sus principales controles para limitar quién ve los datos de los clientes, por lo que los auditores suelen preguntar por él. Esto no es asesoría legal ni de cumplimiento. Nuestro artículo sobre permisos de Salesforce y PHI profundiza en los datos de salud.
¿Quiere una segunda opinión sobre su modelo de uso compartido?
Podemos revisar sus valores predeterminados de toda la org, su jerarquía y sus reglas de uso compartido, y decirle dónde el acceso está demasiado abierto o demasiado restringido. Reserve una revisión gratuita de Salesforce.