Microsoft incluye muchos roles predefinidos que cubren los casos de uso más comunes. Conocerlos te ahorrará tiempo y te ayudará a diseñar roles personalizados a partir de una base sólida.
Objetivos de aprendizaje
- Identificar los roles predefinidos más importantes del sistema
- Entender los casos de uso para cada rol out-of-the-box
- Conocer las mejores prácticas para usar roles predefinidos
- Saber cuándo crear roles personalizados vs usar los existentes
Por qué existen los roles predefinidos
Cuando Microsoft diseñó Dataverse y Dynamics 365, sabía que la mayoría de organizaciones tienen necesidades de seguridad similares. Casi toda empresa tiene administradores de sistema, usuarios básicos, vendedores, agentes de soporte, y demás perfiles comunes. En lugar de obligar a cada organización a crear estos roles desde cero, Microsoft los incluyó de forma predeterminada.
Estos roles "out-of-the-box" (OOB, como se les llama en la comunidad) representan décadas de experiencia acumulada sobre qué permisos necesita típicamente cada tipo de usuario. No son perfectos para toda situación, pero son un excelente punto de partida.
Los roles de sistema fundamentales
Hay tres roles que encontrarás en cualquier entorno de Dataverse, independientemente de qué aplicaciones tengas instaladas. Estos son los pilares del modelo de seguridad.
System Administrator: el rol todopoderoso
El System Administrator es exactamente lo que su nombre sugiere: el administrador absoluto del sistema. Un usuario con este rol puede hacer literalmente cualquier cosa. Tiene todos los privilegios, a nivel Organization, en todas las entidades. Puede modificar la configuración del sistema, cambiar la estructura de seguridad, ver todos los datos, eliminar cualquier registro, importar y exportar personalizaciones... todo.
Hay algo que muchos no saben: el System Administrator también ignora la seguridad a nivel de campo. Incluso si has configurado Field Security para ocultar ciertos campos sensibles (como salarios o números de seguridad social), un System Administrator los verá de todos modos. El sistema está diseñado así intencionalmente, porque un administrador del sistema necesita poder diagnosticar y solucionar problemas en cualquier parte del sistema sin restricciones.
Por esta razón, el número de personas con System Administrator debería ser extremadamente limitado. En una organización de 500 personas, probablemente 2-3 personas deberían tener este rol, y deberían ser personal de TI de alto nivel que entiende la responsabilidad que conlleva.
System Customizer: el desarrollador sin datos
El System Customizer es un rol elegante para un problema real: ¿cómo das acceso a desarrolladores y configuradores para que puedan modificar el sistema sin que vean los datos de negocio?
Este rol permite crear y modificar entidades, campos, formularios, vistas, flujos de Power Automate, aplicaciones de Canvas, y prácticamente cualquier aspecto técnico del sistema. Pero por defecto, no tiene acceso a los datos de las entidades de negocio.
Esto es perfecto para equipos de desarrollo en entornos de producción. El desarrollador puede hacer su trabajo de configuración sin poder ver las oportunidades reales de ventas, los casos de soporte con información de clientes, o cualquier otro dato sensible.
Un matiz importante: el System Customizer SÍ puede ver datos de las entidades del sistema (configuración, metadatos, etc.), y si configuras mal sus permisos adicionales, podría acabar viendo más de lo esperado. Pero como punto de partida, es mucho más seguro que System Administrator para personal técnico.
Basic User: el punto de partida universal
Basic User es el rol más simple que le da a alguien acceso funcional al sistema. No puede hacer mucho por sí solo: principalmente tiene acceso de lectura a nivel User en varias entidades, puede crear y gestionar sus propias actividades (tareas, llamadas, correos), y tiene los permisos mínimos para navegar la interfaz.
Lo interesante de Basic User es que está diseñado para ser combinado con otros roles. La filosofía es: "dale Basic User a todos, luego añade roles adicionales según las funciones específicas que necesiten". Esto es más mantenible que crear roles monolíticos gigantes porque puedes reutilizar componentes.
Por ejemplo, alguien de ventas tendría: Basic User + Salesperson. Alguien de soporte tendría: Basic User + Customer Service Representative. Un gerente de ventas tendría: Basic User + Salesperson + Sales Manager.
Roles específicos de aplicaciones de Dynamics 365
Cada aplicación de Dynamics 365 viene con sus propios roles predefinidos que reflejan los perfiles típicos de usuarios de esa aplicación.
Roles de Dynamics 365 Sales
La aplicación de Sales viene con una jerarquía de roles que refleja la estructura típica de un equipo de ventas:
Salesperson es el vendedor individual. Tiene acceso completo a nivel User en las entidades clave de ventas: leads, oportunidades, cuentas, contactos, ofertas, pedidos. Puede gestionar todo su pipeline personal, pero no ve lo que están haciendo sus compañeros (a menos que se lo compartan explícitamente).
Sales Manager es el gerente de equipo. Tiene todo lo de Salesperson, pero con acceso a nivel Business Unit en lugar de User para las entidades críticas. Esto le permite ver y supervisar el trabajo de todos los vendedores en su unidad de negocio. También tiene privilegios adicionales para gestionar equipos y generar reportes.
VP of Sales es el director comercial. Sus privilegios están a nivel Parent:Child, lo que significa que puede ver toda la organización de ventas, incluyendo todas las regiones subordinadas. Es el rol apropiado para alguien que necesita una vista completa del pipeline comercial de la empresa.
Roles de Dynamics 365 Customer Service
Customer Service tiene su propia jerarquía:
Customer Service Representative (CSR) es el agente de soporte de primera línea. Puede crear y gestionar casos, consultar la base de conocimiento, trabajar con colas de servicio, y registrar actividades de atención al cliente. Sus privilegios están generalmente a nivel User o Business Unit dependiendo de cómo esté organizado el centro de contacto.
Customer Service Manager supervisa el equipo de agentes. Tiene visibilidad en todos los casos de su equipo, puede reasignar casos, monitorear SLAs, y tiene acceso a dashboards de rendimiento del equipo.
La regla de oro: nunca modifiques roles out-of-the-box
Esta es posiblemente la mejor práctica más importante que puedo compartirte sobre roles de seguridad: nunca modifiques directamente un rol predefinido de Microsoft.
¿Por qué? Varias razones:
Primero, Microsoft actualiza estos roles periódicamente. Cuando se añaden nuevas funcionalidades al sistema, a veces es necesario añadir nuevos privilegios a los roles existentes. Si has modificado el rol, pueden pasar cosas impredecibles durante las actualizaciones.
Segundo, pierdes la referencia de cómo era el rol original. Si algo deja de funcionar, es difícil saber si el problema es tu modificación o algo completamente diferente.
Tercero, dificulta el soporte. Si contactas a Microsoft Support y les dices "el rol Salesperson no funciona bien", lo primero que van a verificar es si lo has modificado. Y si lo has hecho, te van a pedir que pruebes con un rol sin modificar.
La alternativa correcta: copiar y personalizar
En lugar de modificar roles OOB, sigue este proceso:
Abre el rol que quieres usar como base (por ejemplo, Salesperson). Usa la opción "Guardar como" o "Save As" para crear una copia. Dale a la copia un nombre claro que indique que es personalizado y para qué es: "Contoso - Vendedor Regional" o "Salesperson - Sin Delete".
Ahora modifica la copia todo lo que necesites. Añade privilegios, quita privilegios, cambia niveles de acceso. La copia es tuya para hacer lo que quieras.
Mantén el rol original intacto como referencia. Si algún día necesitas comparar o empezar de nuevo, ahí lo tienes.
Cuándo crear roles personalizados desde cero
No siempre tiene sentido empezar desde un rol OOB. A veces es mejor crear un rol completamente nuevo:
Si tienes entidades personalizadas que no existen en el sistema estándar, ningún rol OOB tendrá privilegios para ellas. Tendrás que crear un rol específico que defina qué usuarios pueden hacer qué con esas entidades.
Si tu organización tiene perfiles de usuario muy específicos que no encajan con ningún rol predefinido, puede ser más limpio crear desde cero en lugar de modificar uno existente hasta hacerlo irreconocible.
Si necesitas un rol muy restrictivo como punto de partida, a veces es más fácil crear un rol vacío y añadir solo los privilegios necesarios, en lugar de partir de un rol con muchos privilegios e ir quitando.
Puntos clave
- System Administrator tiene acceso absoluto e ignora Field Security - resérvalo para muy pocos
- System Customizer permite configurar el sistema sin acceso a datos de negocio
- Basic User es un buen punto de partida para combinar con otros roles
- Cada app de D365 incluye roles específicos (Salesperson, CSR, etc.)
- Nunca modifiques roles OOB directamente - crea copias
- Crea roles desde cero cuando tengas entidades personalizadas o perfiles muy específicos