Esta lección profundiza en la configuración detallada de privilegios, mostrando casos prácticos del mundo real y ayudándote a diagnosticar los problemas de permisos que inevitablemente encontrarás.
Objetivos de aprendizaje
- Dominar la configuración detallada de privilegios en roles
- Entender las implicaciones prácticas de cada nivel de acceso
- Resolver escenarios comunes de permisos
- Diagnosticar problemas relacionados con privilegios
Las dependencias ocultas entre privilegios
Una de las fuentes más comunes de frustración al configurar roles de seguridad es no entender que los privilegios no funcionan de forma aislada. Hay dependencias implícitas que, si no las conoces, te harán perder horas intentando entender por qué algo no funciona.
Write requiere Read
Esto parece obvio cuando lo piensas: ¿cómo vas a editar algo que no puedes ver? Pero es sorprendentemente común olvidarlo. He visto roles donde alguien ha dado Write a nivel Business Unit pero Read solo a nivel User. El usuario puede ver sus propios registros, pero cuando intenta editar un registro de un compañero de la misma BU, ve un error. Técnicamente tiene permiso para escribir en ese registro, pero como no puede leerlo, la operación falla en el primer paso.
La regla es simple: Read debe estar siempre al menos al mismo nivel que Write. Si tienes Write a nivel BU, Read debe ser BU o superior. Si tienes Write a nivel Organization, Read debe ser Organization.
Delete requiere Read
El mismo principio aplica a Delete. No puedes eliminar lo que no puedes ver. Si das Delete a nivel BU pero Read solo a nivel User, el usuario podrá eliminar sus propios registros pero no los de sus compañeros, aunque teóricamente tenga el privilegio.
Assign requiere Write
Asignar un registro a otro usuario significa cambiar el campo Owner, que es un tipo de modificación. Por tanto, necesitas Write además de Assign. En algunos escenarios también podrías necesitar Read, dependiendo de cómo esté implementada la lógica de la aplicación.
Las relaciones requieren Append + AppendTo
Este es el caso más confuso y el que causa más problemas. Cuando asocias un registro a otro, Dataverse verifica DOS privilegios:
Primero, verifica que tengas Append en la entidad del registro que se está asociando. Si estás asociando un Contacto a una Cuenta, necesitas Append en Contacto.
Segundo, verifica que tengas AppendTo en la entidad del registro destino. Siguiendo el ejemplo, necesitas AppendTo en Cuenta.
Si falta cualquiera de los dos, la operación falla. Y el mensaje de error suele ser críptico: algo como "Principal user is missing privileges" sin especificar cuál.
Esto se vuelve más complejo cuando creas registros con lookups ya poblados. Si creas una Oportunidad y en el formulario de creación seleccionas una Cuenta relacionada, en ese momento estás haciendo dos cosas: creando la Oportunidad (necesitas Create) y asociándola a la Cuenta (necesitas Append en Opportunity y AppendTo en Account). Si falta alguno, la creación falla.
Los niveles de acceso en la práctica
Ya hemos visto los cinco niveles de acceso (User, Business Unit, Parent:Child, Organization, y None), pero verlos en acción con escenarios reales ayuda a solidificar el entendimiento.
Escenario 1: El vendedor independiente
Juan es un vendedor de campo que trabaja sus propias cuentas. No necesita ver lo que hacen sus compañeros, y definitivamente no debería poder modificar sus registros.
Para Juan, configuramos todos los privilegios a nivel User:
- Read: User - solo ve sus propias oportunidades, cuentas, contactos
- Create: User - puede crear nuevos registros (que automáticamente le pertenecerán)
- Write: User - puede editar solo sus propios registros
- Delete: None - los vendedores no deberían poder eliminar, solo desactivar
El resultado es que Juan vive en su propia burbuja dentro del sistema. Ve un pipeline de ventas que contiene exclusivamente su trabajo. Si un cliente llama preguntando por una oportunidad de otro vendedor, Juan no podrá ayudar porque ni siquiera verá que esa oportunidad existe.
Escenario 2: El equipo colaborativo
El equipo de ventas de la oficina de Madrid trabaja de forma muy colaborativa. Comparten cuentas, se cubren entre ellos cuando alguien está de vacaciones, y necesitan visibilidad completa del trabajo del equipo.
Para este equipo, los privilegios están a nivel Business Unit:
- Read: Business Unit - todos ven las oportunidades de todos en el equipo
- Write: User - pero cada uno solo puede editar las suyas
- Create: User - crean sus propios registros
Esta configuración permite colaboración sin caos. María puede ver las oportunidades de Pedro y entender el contexto si un cliente de Pedro llama cuando él no está. Pero no puede modificar las oportunidades de Pedro (a menos que Pedro se las comparta específicamente), lo que evita pisarse el trabajo entre compañeros.
Escenario 3: El gerente regional
Carmen es la gerente de la región Norte, que incluye las oficinas de Madrid, Barcelona y Valencia. Cada oficina es una unidad de negocio separada, pero todas están bajo "Región Norte" en la jerarquía.
Carmen necesita supervisar todas las oficinas sin poder modificar directamente el trabajo de los vendedores:
- Read: Parent:Child - ve las oportunidades de Madrid, Barcelona, Valencia y cualquier otra oficina subordinada
- Write: User - solo puede editar los registros que ella posee directamente
- Assign: Parent:Child - puede reasignar oportunidades entre vendedores de diferentes oficinas si es necesario
Con esta configuración, Carmen tiene visibilidad total para su función de supervisión, pero no interfiere con el trabajo diario de los vendedores. Si necesita intervenir (por ejemplo, reasignar una oportunidad crítica cuando un vendedor está enfermo), tiene el privilegio Assign para hacerlo.
Escenario 4: El director de ventas
Luis es el director comercial de toda la empresa. Necesita ver absolutamente todo para preparar reportes ejecutivos y tomar decisiones estratégicas.
- Read: Organization - ve todas las oportunidades de toda la empresa
- Write: None o User - no necesita modificar nada, solo ver
Fíjate que incluso a nivel ejecutivo, no damos más privilegios de los necesarios. Luis necesita ver todo, pero no necesita poder editarlo. Si le diéramos Write a nivel Organization "por si acaso", estaríamos creando un riesgo innecesario de modificaciones accidentales.
Diagnosticando problemas de permisos
Tarde o temprano, recibirás un mensaje así: "No puedo acceder a X" o "Me sale un error cuando intento hacer Y". Cuando esto pase, sigue este flujo sistemático de diagnóstico.
Paso 1: Verificar la licencia
Antes de mirar roles, confirma que el usuario tiene una licencia válida y apropiada. La licencia es la primera barrera de seguridad. Si el usuario tiene licencia Team Member e intenta crear oportunidades, ningún rol puede ayudarle - la licencia lo bloquea.
Paso 2: Verificar que está habilitado en el entorno
Un usuario puede tener licencia pero no estar habilitado en el entorno específico donde intenta trabajar. Comprueba en Configuración > Usuarios que el usuario existe y está habilitado.
Paso 3: Revisar los roles asignados
¿Tiene el usuario algún rol asignado? ¿Son los roles correctos para lo que intenta hacer? Ve al registro del usuario y revisa la lista de roles.
Paso 4: Revisar privilegios específicos
Abre cada rol y verifica si tiene el privilegio necesario para la entidad en cuestión. Si el usuario no puede ver oportunidades, busca el privilegio Read en la entidad Opportunity. Si no puede crearlas, busca Create.
Paso 5: Verificar el nivel de acceso
Tener el privilegio no es suficiente - el nivel debe ser apropiado. Si tiene Read a nivel User pero intenta ver un registro de otra persona, ese es el problema.
Paso 6: Revisar Field Security
Si el usuario puede ver el registro pero no ciertos campos, el problema probablemente está en Field Security. Revisa si hay perfiles de seguridad de campo aplicados y si el usuario está incluido en ellos.
Paso 7: Esperar el caché
Si acabas de hacer cambios en roles, el caché de seguridad puede tardar 5-15 minutos en actualizarse. Pide al usuario que cierre sesión completamente y vuelva a entrar, o simplemente espera un poco antes de declarar que hay un problema real.
Casos especiales que causan confusión
Entidades con propiedad de organización
Algunas entidades no tienen un propietario individual - toda la organización las "posee". Productos, listas de precios, monedas, unidades... estas entidades son compartidas. Para ellas, el nivel de acceso User no tiene sentido (no hay un "propietario"), así que en la práctica funcionan como si todos los privilegios fueran a nivel Organization.
Registros compartidos
Cuando alguien comparte un registro contigo, te da acceso más allá de lo que tus roles permiten. Esto puede crear confusión cuando intentas diagnosticar problemas: "María puede ver este registro, así que su rol está bien". Pero quizás María puede verlo porque se lo compartieron, no porque su rol lo permita.
Equipos de propietarios
Si un usuario pertenece a un equipo, y ese equipo posee registros, el usuario puede tener acceso a esos registros incluso si su rol individual no lo permitiría. Esto es intencional y útil, pero puede complicar el diagnóstico.
Puntos clave
- Read debe estar al menos al mismo nivel que Write y Delete
- Las relaciones entre registros requieren Append + AppendTo en las dos entidades involucradas
- Empieza siempre con nivel User y expande solo cuando hay necesidad clara
- Para datos sensibles, usa Field Security en lugar de niveles de acceso restrictivos
- Sigue el flujo de diagnóstico sistemáticamente: licencia → habilitado → roles → privilegios → nivel → field security → caché
- Recuerda que compartir y equipos pueden otorgar acceso más allá de lo que los roles permiten