Los roles de seguridad son el corazón del sistema de autorización en Dataverse. En esta lección desglosaremos cada componente de un rol para que puedas configurarlos con confianza.
Objetivos de aprendizaje
- Comprender la estructura interna completa de un rol de seguridad
- Dominar los 8 tipos de privilegios disponibles
- Entender los 5 niveles de acceso y cuándo usar cada uno
- Interpretar correctamente la matriz de privilegios en la interfaz
¿Qué es exactamente un rol de seguridad?
Imagina que trabajas en una empresa grande. No todos los empleados tienen acceso a las mismas oficinas, archivos o sistemas. El recepcionista no necesita entrar al laboratorio de I+D, y el ingeniero no necesita acceso a los expedientes de recursos humanos. Los roles de seguridad en Dataverse funcionan exactamente igual: son como "pases de acceso" que definen qué puede hacer cada persona en el sistema.
Un rol de seguridad es, en esencia, una colección organizada de permisos. Cuando asignas un rol a un usuario, le estás diciendo al sistema: "Esta persona puede hacer X, Y y Z, pero no puede hacer A, B ni C". Lo interesante es que no defines esto para cada usuario individualmente (eso sería una pesadilla administrativa), sino que creas roles que representan "tipos" de usuarios y luego asignas esos roles a las personas.
Por ejemplo, en lugar de configurar permisos para María, Juan, Pedro y los otros 50 vendedores uno por uno, creas un rol llamado "Vendedor" con todos los permisos que necesita un vendedor típico, y se lo asignas a todos ellos. Si mañana contratas 10 vendedores más, simplemente les asignas el mismo rol y ya tienen todo configurado.
Los componentes internos de un rol
Cuando abres un rol de seguridad en Dataverse, te encuentras con una estructura que puede parecer abrumadora al principio. Hay filas, columnas, círculos de colores... pero una vez que entiendes la lógica, todo cobra sentido.
Cada rol contiene cuatro elementos principales:
El nombre y descripción parecen obvios, pero son más importantes de lo que crees. Un nombre como "Custom Role 1" no le dice nada a nadie, pero "Vendedor Regional - Solo Lectura" deja claro inmediatamente para qué sirve ese rol. La descripción es tu oportunidad de documentar para qué se usa, quién debería tenerlo y cualquier consideración especial.
La unidad de negocio asociada al rol determina en qué parte de la organización existe ese rol. Esto es relevante porque cuando copias un rol a otra unidad de negocio, se crea una versión independiente que puedes modificar sin afectar al original.
La matriz de privilegios por entidad es donde está la sustancia del rol. Aquí defines, para cada tabla del sistema (Account, Contact, Opportunity, etc.), qué acciones puede realizar el usuario y con qué alcance.
Finalmente, los privilegios misceláneos y de privacidad controlan funciones especiales que no están asociadas a una tabla en particular, como la capacidad de exportar a Excel o hacer eliminaciones masivas.
Los 8 privilegios fundamentales explicados
En Dataverse, todas las acciones que puedes hacer sobre un registro se reducen a 8 privilegios fundamentales. Entenderlos bien es la base para configurar cualquier rol de seguridad correctamente.
Create (Crear)
El privilegio Create permite al usuario añadir nuevos registros a una tabla. Parece simple, pero hay matices importantes. Cuando creas un registro, automáticamente te conviertes en su propietario (a menos que lo asignes a otra persona durante la creación). Esto significa que el privilegio Create está íntimamente ligado con los niveles de acceso que veremos más adelante.
Un escenario común: un vendedor con Create a nivel User puede crear nuevas oportunidades, y esas oportunidades le pertenecerán a él. Pero no podrá crear oportunidades "en nombre de" otro vendedor a menos que también tenga el privilegio Assign.
Read (Leer)
Read es probablemente el privilegio más fundamental. Sin él, el usuario literalmente no puede ver que existe un registro. No aparecerá en listas, no podrá abrirlo, no podrá buscarlo. Es como si ese registro no existiera para esa persona.
Lo que mucha gente no sabe es que Read también es un prerrequisito para casi todo lo demás. No puedes editar algo que no puedes ver. No puedes eliminar algo que no puedes ver. Por eso, cuando configures otros privilegios, asegúrate de que Read esté al menos al mismo nivel.
Write (Escribir)
Write permite modificar registros existentes. Cambiar el teléfono de un contacto, actualizar el estado de una oportunidad, corregir la dirección de una cuenta... todo eso requiere Write.
Un detalle importante: Write te permite modificar los campos "normales" de un registro, pero hay algunos campos del sistema que requieren privilegios específicos. Por ejemplo, cambiar el propietario de un registro requiere Assign, no Write. Y si tienes Field Security habilitado en algún campo, Write no es suficiente para modificar ese campo – necesitas además estar en el perfil de seguridad de campo correspondiente.
Delete (Eliminar)
Delete permite borrar registros permanentemente. Este es un privilegio que deberías otorgar con mucha cautela. A diferencia de Write (donde un error se puede corregir), Delete es frecuentemente irreversible. Sí, existe la Papelera de reciclaje de Dataverse que retiene registros eliminados durante un tiempo, pero depender de ella como plan de respaldo no es una buena estrategia.
En muchas organizaciones, solo los administradores tienen Delete, y los usuarios regulares "desactivan" registros en lugar de eliminarlos. Esto preserva el historial y permite recuperar datos si alguien comete un error.
Append (Anexar)
Aquí es donde las cosas se ponen interesantes. Append no es intuitivo al principio, pero es crucial para que las relaciones entre registros funcionen.
Append significa "puedo asociar ESTE registro a otro registro". Por ejemplo, si tienes un Contacto y quieres asociarlo a una Cuenta, necesitas Append en Contacto. El Contacto es el que "se anexa" a la Cuenta.
Piénsalo como pegar un post-it. El Contacto es el post-it, y necesitas permiso para pegar ese post-it en algún lugar.
AppendTo (Anexar a)
AppendTo es el complemento de Append. Mientras que Append te da permiso para que un registro SE ANEXE a otro, AppendTo te da permiso para que otros registros SE ANEXEN A este registro.
Siguiendo el ejemplo anterior: si tienes un Contacto y quieres asociarlo a una Cuenta, además de Append en Contacto, necesitas AppendTo en Cuenta. La Cuenta es la que "recibe" al Contacto que se le anexa.
Es como tener permiso para que te peguen post-its encima. Sin AppendTo en Cuenta, aunque el usuario tenga Append en Contacto, la operación fallará.
Assign (Asignar)
Assign permite cambiar el propietario de un registro. Esto es particularmente importante en escenarios donde los registros cambian de manos: un lead que se convierte y se asigna a un vendedor, un caso de soporte que se escala a otro agente, etc.
Un matiz importante: Assign incluye implícitamente la capacidad de modificar el campo Owner, pero técnicamente también necesitas Write porque estás modificando el registro. En la práctica, si tienes Assign sin Write, algunas operaciones pueden fallar dependiendo de cómo esté implementada la lógica.
Share (Compartir)
Share es el mecanismo de Dataverse para excepciones a las reglas normales de seguridad. Normalmente, el acceso a un registro está determinado por los niveles de acceso del rol. Pero a veces necesitas dar acceso temporal o específico a alguien que normalmente no lo tendría.
Por ejemplo: María es vendedora en la región Este y normalmente solo ve oportunidades de su unidad de negocio. Pero para un proyecto especial, necesita colaborar con Juan de la región Oeste en una oportunidad específica. En lugar de cambiar todo el modelo de seguridad, Juan puede "compartir" esa oportunidad específica con María.
Share crea lo que se llama un "POA record" (Principal Object Access) que otorga permisos específicos a usuarios o equipos específicos para registros específicos, sin cambiar nada más del modelo de seguridad.
Los 5 niveles de acceso: el alcance de tus privilegios
Tener un privilegio no es suficiente; también necesitas saber qué tan lejos llega ese privilegio. Aquí es donde entran los niveles de acceso.
Imagina que tienes el privilegio Read en la entidad Oportunidad. ¿Significa eso que puedes ver TODAS las oportunidades de la empresa? No necesariamente. El nivel de acceso determina cuáles oportunidades puedes ver.
Nivel User (Usuario)
Este es el nivel más restrictivo. Con acceso a nivel User, solo puedes actuar sobre registros que te pertenecen directamente (donde tú eres el Owner) o que se han compartido contigo específicamente.
Este nivel es perfecto para situaciones donde cada persona gestiona su propio trabajo. Un vendedor con Read a nivel User en Oportunidades solo verá sus propias oportunidades. No verá las de sus compañeros, ni las de otros departamentos, ni las de otras regiones. Solo las suyas.
Nivel Business Unit (Unidad de Negocio)
Con acceso a nivel Business Unit, puedes actuar sobre registros que pertenecen a cualquier usuario de tu misma unidad de negocio.
Este nivel es ideal para equipos que colaboran estrechamente. Si tienes un equipo de 5 vendedores en la oficina de Madrid, todos en la misma unidad de negocio "Ventas Madrid", darles Read a nivel BU en Oportunidades significa que cada uno puede ver las oportunidades de todos los demás compañeros del equipo. Esto facilita la colaboración: si un cliente llama y su vendedor asignado no está disponible, cualquier otro del equipo puede ver el contexto y ayudar.
Nivel Parent:Child (Principal y Secundarias)
Este nivel extiende el acceso a tu unidad de negocio más todas las unidades de negocio que están "debajo" de la tuya en la jerarquía.
Es el nivel típico para managers y supervisores. Imagina esta estructura:
Ventas España (BU padre)
├── Ventas Madrid
├── Ventas Barcelona
└── Ventas Valencia
Un gerente que está en "Ventas España" con Read a nivel Parent:Child podrá ver las oportunidades de todas las oficinas subordinadas (Madrid, Barcelona, Valencia), además de cualquier oportunidad que pertenezca directamente a "Ventas España".
Pero un vendedor en "Ventas Madrid" con Read a nivel Parent:Child solo vería las de Madrid (no tiene unidades hijas).
Nivel Organization (Organización)
El nivel más amplio. Con acceso a nivel Organization, puedes actuar sobre todos los registros de esa entidad en todo el sistema, sin importar quién sea el propietario, en qué unidad de negocio esté, ni ningún otro criterio.
Este nivel debe usarse con precaución y generalmente se reserva para:
- Administradores: que necesitan gestionar todo el sistema
- Datos de referencia: como productos, listas de precios o monedas que todos necesitan leer
- Reportes ejecutivos: donde un director necesita ver métricas de toda la empresa
El error más común es dar Organization "porque es más fácil". Sí, es más fácil de configurar, pero elimina el propósito de tener seguridad en primer lugar.
Nivel None (Ninguno)
Técnicamente hay un quinto nivel: None, que significa que el usuario no tiene ese privilegio en absoluto. En la interfaz aparece como un círculo vacío.
Privilegios Misceláneos y de Privacidad
Hasta ahora hemos hablado de privilegios que aplican a tablas específicas. Pero hay otra categoría de privilegios que controlan acciones del sistema que no están asociadas a ninguna tabla en particular.
Privilegios Misceláneos
Estos controlan funciones administrativas y operaciones especiales. Los más importantes son:
prvBulkDelete permite ejecutar trabajos de eliminación masiva. Es extremadamente poderoso y potencialmente destructivo. Un usuario con este privilegio puede eliminar miles de registros con unos pocos clics. Resérvalo para administradores.
prvBulkEdit permite editar múltiples registros a la vez. Menos destructivo que BulkDelete, pero aún así puede causar problemas si alguien actualiza mal miles de registros.
prvMerge permite combinar registros duplicados. Esto es útil para limpieza de datos, pero la combinación es generalmente irreversible.
prvActOnBehalfOfAnotherUser es uno de los privilegios más sensibles. Permite a una cuenta "actuar como" otro usuario, ejecutando código o API calls en su nombre. Esto es necesario para ciertas integraciones técnicas, pero nunca debería darse a usuarios humanos regulares.
Privilegios de Privacidad
Estos controlan la capacidad de sacar datos del sistema. En un mundo con GDPR, CCPA y otras regulaciones de privacidad, estos privilegios son críticos:
prvExportToExcel permite exportar datos a Excel. Parece inocente, pero un usuario malintencionado (o simplemente descuidado) podría exportar toda tu base de datos de clientes a un archivo que luego comparte por email.
prvGoOffline permite trabajar en modo offline, lo que significa que los datos se descargan al dispositivo local. Si ese dispositivo se pierde o es robado, los datos están expuestos.
prvPrint permite imprimir registros. Los documentos impresos son difíciles de rastrear y pueden acabar en lugares inesperados.
La interfaz del editor de roles
Cuando abres un rol de seguridad, verás una matriz que puede parecer abrumadora al principio. Vamos a descomponerla:
Las filas representan entidades (tablas) del sistema. Verás nombres como Account, Contact, Opportunity, Lead, etc. También verás tus entidades personalizadas si las tienes.
Las columnas representan los 8 privilegios fundamentales que hemos discutido.
Las celdas contienen círculos que indican el nivel de acceso. Los círculos vacíos significan "ningún acceso". Los círculos coloreados indican diferentes niveles: amarillo para User, verde para Business Unit, azul oscuro para Parent:Child, y dorado/púrpura para Organization.
El editor también tiene pestañas o secciones para los privilegios misceláneos y de privacidad, que funcionan de manera similar pero sin la matriz de entidades.
Puntos clave
- Un rol de seguridad es una colección de privilegios que defines una vez y asignas a múltiples usuarios
- Los 8 privilegios fundamentales cubren todas las acciones: Create, Read, Write, Delete, Append, AppendTo, Assign, Share
- Append y AppendTo trabajan en conjunto: el registro que "se pega" necesita Append, el que "recibe" necesita AppendTo
- Los 5 niveles de acceso determinan el alcance: User (solo tuyos), BU (tu equipo), Parent:Child (tu equipo + subordinados), Organization (todos)
- Los privilegios misceláneos controlan operaciones del sistema como eliminación masiva o importación
- Los privilegios de privacidad controlan la exportación de datos y tienen implicaciones de compliance