OWD, role hierarchy y sharing rules en Salesforce

El modelo mental: cerrar primero, abrir despues

En Salesforce, la seguridad de registros funciona mejor cuando piensas en capas. Primero debe existir permiso para usar el objeto. Despues se define que registros puede ver o editar cada usuario. Organization-wide defaults establecen la base para registros que el usuario no posee. Si esa base es restrictiva, otras herramientas abren acceso de manera selectiva: role hierarchy, sharing rules, manual sharing, teams, territory management u otros mecanismos segun el caso.

La idea clave es que OWD, role hierarchy y sharing rules no reemplazan object permissions ni field-level security. Si un usuario no tiene Read sobre Opportunity, una sharing rule no arregla el problema. Si tiene Read sobre Opportunity pero no ve oportunidades de otros usuarios porque OWD es privado, entonces si estas ante un problema de record access. Esta diferencia aparece constantemente en preguntas de examen.

Regla practica: object permission responde "puede usar este objeto"; field-level security responde "puede ver este campo"; sharing responde "puede ver este registro especifico".

Organization-wide defaults

Organization-wide defaults, u OWD, definen el nivel de acceso predeterminado que los usuarios tienen sobre registros que no son de su propiedad. En otras palabras, OWD responde que tan abierto o cerrado queda cada objeto antes de aplicar excepciones. Para muchos objetos, los modelos tipicos son Private, Public Read Only y Public Read/Write. Algunos objetos tienen opciones especiales como Controlled by Parent.

Un buen administrador no elige OWD pensando en el usuario promedio; lo elige pensando en el usuario mas restringido que aun necesita trabajar con ese objeto. Si la persona mas restringida nunca deberia ver registros de otros, Private suele tener sentido. Si todos pueden ver registros pero solo los propietarios deben editarlos, Public Read Only es candidato. Si todos pueden ver y editar todo el objeto, Public Read/Write es posible, pero debe justificarse con cuidado.

En preguntas de certificacion, OWD suele aparecer cuando se habla de baseline access, default internal access, records users do not own, private records o access model. Recuerda que OWD puede cerrar la base, pero no concede mas permisos de objeto de los que el usuario ya tiene. Tampoco se usa para hacer excepciones puntuales; para eso vienen las capas de apertura.

Role hierarchy

La jerarquia de roles abre acceso vertical. Los usuarios ubicados por encima en la jerarquia pueden acceder a registros poseidos por usuarios debajo de ellos, siempre dentro de lo permitido por el modelo de sharing. Esto sirve para escenarios de supervision: gerentes que necesitan ver oportunidades de sus representantes, directores que necesitan visibilidad de sus gerentes o responsables regionales que requieren reportes sobre su equipo.

Role hierarchy no es lo mismo que organigrama. Debe modelar necesidades de acceso a datos, no necesariamente titulos o lineas exactas de reporte. A veces varios puestos se consolidan en un mismo rol porque necesitan el mismo acceso. A veces una persona en el organigrama no necesita acceso a todos los registros de otra. El examen premia reconocer esta diferencia.

En objetos personalizados, Salesforce permite controlar la opcion Grant Access Using Hierarchies en ciertos casos. Para objetos estandar, la jerarquia tiene comportamientos mas establecidos. Si una pregunta menciona que los managers deben ver los registros de sus subordinados, role hierarchy suele ser candidato fuerte. Si los usuarios que necesitan acceso no estan en la misma linea jerarquica, probablemente necesitas otra herramienta.

Las sharing rules son excepciones automaticas al modelo base de OWD. Permiten abrir acceso a usuarios agrupados por rol, rol y subordinados, territorio o public groups. La regla responde tres preguntas: que registros se comparten, con quien se comparten y con que nivel de acceso. Los registros pueden seleccionarse por propietario o por criterios basados en valores de campos.

Sharing rules solo abren acceso; no lo restringen por debajo de OWD. Si OWD ya es Public Read/Write, una sharing rule no aporta mucho porque todos ya tienen acceso amplio. Si OWD es Private o Public Read Only, una sharing rule puede otorgar Read Only o Read/Write a un grupo especifico que necesita colaborar con registros que no posee.

Busca sharing rules cuando la pregunta diga que un conjunto de usuarios fuera de la jerarquia necesita acceso automatico y repetible. Por ejemplo, un equipo legal necesita ver contratos de ciertas regiones, soporte necesita leer cuentas de clientes premium o marketing necesita acceso a campañas con cierto estado. Si el criterio es estable, automatico y aplica a muchos registros, sharing rule es mas limpia que manual sharing.

Manual sharing, teams y territories

No todo problema de registros se resuelve con role hierarchy o sharing rules. Manual sharing sirve para excepciones individuales cuando un propietario o usuario autorizado comparte un registro especifico. Es util si el caso es poco frecuente, no si se repite todos los dias. Si el examen dice one-off, ad hoc o single record, manual sharing puede aparecer como opcion razonable.

Account Teams, Opportunity Teams y Case Teams ayudan cuando varias personas colaboran alrededor de registros concretos. En lugar de abrir una regla amplia, puedes representar colaboradores del registro y controlar acceso segun su rol en el equipo. Territory management ayuda cuando el acceso depende de territorios comerciales y estructuras de ventas mas complejas, no solo de una jerarquia gerencial simple.

Public groups son piezas de apoyo. No son una solucion de sharing por si solos, pero simplifican con quien compartes. Puedes crear un grupo con usuarios, roles, roles y subordinados u otros grupos, y usarlo en sharing rules o configuraciones relacionadas. En examen, public group suele ser parte de la respuesta cuando necesitas compartir con una combinacion de usuarios que no encaja limpiamente en una sola rama de roles.

Trampas comunes al estudiar sharing

La primera trampa es intentar arreglar record visibility con permission sets. Un permission set puede otorgar Read, Create, Edit o Delete sobre un objeto, pero no decide automaticamente que registros de otros usuarios son visibles. Si la pregunta dice que el usuario puede ver sus propias oportunidades pero no las de su equipo, probablemente no falta permiso de objeto; falta apertura de registros.

La segunda trampa es usar role hierarchy para acceso horizontal. Si dos equipos al mismo nivel necesitan compartir registros entre si, subir o mover roles puede distorsionar el modelo. Una sharing rule hacia un public group puede ser mejor. La tercera trampa es usar manual sharing para necesidades recurrentes. Si todos los casos premium deben ser visibles para un grupo de soporte, automatiza con una regla o herramienta especifica; no dependas de que alguien comparta uno por uno.

La cuarta trampa es olvidar que cambios grandes de OWD o jerarquia pueden recalcular acceso y afectar rendimiento en organizaciones grandes. En el examen de Administrator normalmente no necesitas detalles profundos de arquitectura, pero si debes entender que cambiar el modelo base no es una decision ligera. Si la necesidad es una excepcion limitada, evita respuestas que cambian OWD para toda la organizacion.

Como reconocer la respuesta correcta

Empieza preguntando si el problema es funcional o de visibilidad. Si el usuario no puede crear, editar o eliminar registros propios, revisa object permissions, profile o permission set. Si puede trabajar con sus registros pero no con registros de otros, revisa OWD, role hierarchy y sharing. Despues identifica el patron: vertical, horizontal, individual o territorial.

Vertical suele apuntar a role hierarchy: gerente ve lo de subordinados. Horizontal o entre grupos suele apuntar a sharing rules. Individual o temporal suele apuntar a manual sharing. Colaboracion alrededor de cuentas, oportunidades o casos puede apuntar a teams. Segmentacion de ventas por geografia, industria o cuentas puede apuntar a territories. Si la pregunta pide establecer la base mas restrictiva, OWD aparece antes que las excepciones.

Checklist de decision rapida:

El usuario tiene permiso de objeto y de campo?
El problema es con registros propios o registros de otros?
La necesidad de acceso es vertical, horizontal, puntual o territorial?
OWD ya esta abierto o necesita una excepcion?
La solucion abre acceso sin dar mas de lo necesario?

Recursos oficiales y practica

Para estudiar este tema, dibuja escenarios. Escribe el objeto, su OWD, quien posee el registro, quien necesita verlo y que relacion existe entre ambos. Si puedes explicar por que una permission set no resuelve sharing, y por que una sharing rule no concede permisos de objeto, ya tienes la base para responder la mayoria de preguntas de seguridad de registros.

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