En el Módulo 2 vimos los niveles de acceso desde la perspectiva del rol. Ahora profundizamos en el otro lado de la ecuación: cómo la propiedad de cada registro determina quién puede acceder a él.
Objetivos de aprendizaje
- Entender el concepto de ownership en Dataverse
- Configurar correctamente la propiedad de entidades
- Gestionar la reasignación de registros
- Diseñar estrategias de propiedad para diferentes escenarios
El ownership: la otra mitad de la ecuación de seguridad
Cuando hablamos de niveles de acceso en los roles de seguridad (User, Business Unit, Parent:Child, Organization), siempre hay una pregunta implícita: ¿en relación a qué? Si un vendedor tiene Read a nivel User, ¿qué determina cuáles son "sus" registros?
La respuesta es el ownership (propiedad). Cada registro en Dataverse tiene un campo llamado Owner que indica quién es el responsable de ese registro. Este campo es el punto de referencia para evaluar los niveles de acceso.
Cuando Dataverse evalúa si María puede ver una oportunidad específica, el razonamiento es algo así:
- ¿Qué nivel de Read tiene María en Opportunity? → User
- ¿Quién es el Owner de esta oportunidad? → Juan
- ¿María es Juan? → No
- Resultado: María no puede ver esta oportunidad con su privilegio a nivel User
Pero si la oportunidad fuera propiedad de María, o si María tuviera Read a nivel Business Unit y ambos estuvieran en la misma BU, la evaluación cambiaría.
Usuarios vs Equipos como propietarios
El Owner de un registro puede ser un usuario individual o un Owner Team. Esta flexibilidad es muy útil en diferentes escenarios.
Cuando un usuario es el propietario, hay una clara responsabilidad individual. María es dueña de estas 50 oportunidades, son "suyas". Esto funciona bien cuando las personas gestionan su propio trabajo: un vendedor con su pipeline, un agente con sus casos.
Pero ¿qué pasa cuando el trabajo es colaborativo? Si 5 personas trabajan juntas en grandes cuentas corporativas, ¿de quién es cada oportunidad? Si la asignas a María pero Pedro también trabaja en ella, Pedro necesitará algún tipo de acceso adicional.
Aquí es donde los equipos como propietarios brillan. En lugar de asignar la oportunidad a María, la asignas al equipo "Key Accounts". María, Pedro y los demás miembros del equipo automáticamente tienen acceso al registro (asumiendo que sus roles tienen privilegios a nivel User). No hay dependencia de un individuo. Si alguien se va de vacaciones o cambia de rol, los demás continúan sin problemas.
Tipos de propiedad de entidades
No todas las tablas funcionan igual con la propiedad. Cuando creas una entidad personalizada (o cuando Microsoft crea las entidades del sistema), hay que decidir el tipo de propiedad.
Entidades User/Team-owned
La mayoría de entidades de negocio son User or Team-owned. Accounts, Contacts, Opportunities, Cases, Leads... todas tienen un campo Owner. Esto permite toda la granularidad de seguridad que hemos discutido: niveles User, BU, Parent:Child, asignación, compartir.
Cuando creas entidades personalizadas, generalmente deberían ser User or Team-owned a menos que tengas una razón específica para no hacerlo.
Entidades Organization-owned
Algunas entidades son Organization-owned, lo que significa que no tienen un propietario específico. La organización entera las "posee". Ejemplos típicos son datos de referencia: Product, Currency, TransactionCurrency, Units.
Estas entidades no tienen el campo Owner, y los niveles de acceso basados en ownership no aplican. Si tienes Read en Products, tienes Read en todos los productos. Si tienes Create, puedes crear productos que cualquiera puede ver.
No puedes cambiar el tipo de propiedad de una entidad después de crearla. Si creas una entidad como Organization-owned y luego decides que necesitas seguridad a nivel de registro, tendrás que crear una entidad nueva y migrar los datos.
Reasignación de registros
La propiedad no es inmutable. Un registro puede reasignarse de un propietario a otro. Cuando un vendedor deja la empresa, sus oportunidades pueden reasignarse a otro vendedor. Cuando un caso se escala, puede reasignarse a un equipo diferente.
Para reasignar un registro, necesitas el privilegio Assign. Pero no es tan simple como parece. Assign por sí solo no es suficiente; también necesitas Write (porque técnicamente estás modificando el campo Owner) y Read (porque no puedes modificar lo que no puedes ver).
Cascade Behaviors
Cuando reasignas un registro, ¿qué pasa con los registros relacionados? Si reasigno una Cuenta de María a Juan, ¿los Contactos asociados a esa Cuenta también se reasignan?
La respuesta depende de los cascade behaviors configurados en la relación entre las entidades. Hay varias opciones:
Cascade All significa que todos los registros hijos también se reasignan al nuevo propietario. Si reasigno la Cuenta, todos sus Contactos también cambian de owner.
Cascade Active solo reasigna los registros hijos que están activos. Los registros inactivos mantienen su propietario original.
Cascade User-Owned solo reasigna los registros hijos que eran del mismo propietario original. Si la Cuenta era de María y algunos Contactos eran de María pero otros de Pedro, solo los de María se reasignan.
Cascade None no reasigna nada. Los registros hijos mantienen sus propietarios originales.
Entender el cascade behavior es importante porque puede causar cambios inesperados. Reasignar una sola Cuenta podría reasignar docenas o cientos de registros relacionados si el cascade está configurado agresivamente.
Estrategias de propiedad
¿Cómo decides si un registro debería pertenecer a un usuario o a un equipo? Depende del patrón de trabajo:
Si el trabajo es individual (un vendedor gestiona sus propias cuentas, un agente resuelve sus propios casos), la propiedad individual tiene sentido. Es claro quién es responsable de qué.
Si el trabajo es colaborativo (un equipo de key account managers trabaja juntos en grandes cuentas), la propiedad por equipo evita problemas de acceso y dependencia de individuos.
Si el trabajo pasa por fases o colas (un caso nuevo está en una cola, luego se asigna a un agente, luego se escala a un especialista), la propiedad cambiará a lo largo del ciclo de vida del registro.
Puntos clave
- El campo Owner es fundamental para evaluar los niveles de acceso de los roles
- El Owner puede ser un usuario o un Owner Team
- Las entidades User/Team-owned tienen control granular de seguridad; las Organization-owned no
- El privilegio Assign (junto con Read y Write) permite reasignar registros
- Los cascade behaviors determinan qué pasa con registros hijos al reasignar
- Elige propiedad individual para trabajo personal, propiedad de equipo para trabajo colaborativo