Cuando los roles predefinidos no cubren tus necesidades, es hora de crear roles personalizados. En esta lección aprenderás las mejores prácticas para diseñar roles mantenibles y seguros.
Objetivos de aprendizaje
- Diseñar roles personalizados siguiendo mejores prácticas
- Decidir entre roles monolíticos vs modulares
- Implementar un proceso de testing de roles
- Documentar y mantener roles personalizados
El dilema del diseño de roles
He trabajado con muchas organizaciones que llegaron a un punto donde su sistema de roles era un caos incomprensible. "Custom Role 17", "Vendedor Nuevo 2", "Test Role - No Borrar"... nadie sabía qué hacía cada rol ni por qué existía. Reconstruir un sistema así es doloroso y costoso.
La buena noticia es que puedes evitar este destino si piensas estratégicamente desde el principio. El diseño de roles no es solo un ejercicio técnico de asignar permisos; es un ejercicio de arquitectura organizacional.
Dos filosofías de diseño: Monolítico vs Modular
Antes de crear tu primer rol personalizado, necesitas decidir qué enfoque vas a seguir. Esta decisión afectará la mantenibilidad de tu sistema durante años.
El enfoque monolítico
En el enfoque monolítico, creas un rol grande y completo para cada perfil de usuario. El vendedor tiene un rol que contiene absolutamente todo lo que necesita un vendedor. El agente de soporte tiene otro rol con absolutamente todo lo que necesita un agente de soporte. Y así sucesivamente.
Las ventajas son obvias: es simple de entender ("María es vendedora, tiene el rol de vendedor") y simple de asignar (un usuario = un rol). Cuando contratas a alguien nuevo, le asignas un rol y listo.
Pero también tiene desventajas significativas que se vuelven evidentes con el tiempo. Primero, hay duplicación: si tanto vendedores como agentes de soporte necesitan acceso a la entidad "Actividades", tendrás los mismos privilegios definidos en ambos roles. Cuando necesites cambiar algo, tendrás que hacerlo en múltiples lugares.
Segundo, no escala bien. ¿Qué pasa cuando tienes un vendedor que también hace soporte parcialmente? ¿Creas un tercer rol "Vendedor con Soporte"? ¿Y si luego necesitas "Vendedor con Soporte y Acceso a Marketing"? Las combinaciones explotan rápidamente.
El enfoque modular
En el enfoque modular, descompones los permisos en roles pequeños y especializados que se combinan. En lugar de un rol "Vendedor" gigante, tendrías:
Un rol base que todos los empleados tienen, con acceso básico al sistema, su perfil, actividades personales, etc.
Un rol funcional de ventas con acceso a leads, oportunidades, cuentas, contactos y demás entidades de ventas.
Un rol funcional de servicio con acceso a casos, colas, base de conocimiento y demás entidades de soporte.
Un rol de excepción para capacidades específicas que no todos necesitan, como exportar a Excel o hacer eliminaciones masivas.
Un vendedor típico tendría: Rol Base + Rol de Ventas. Un vendedor senior que también puede exportar tendría: Rol Base + Rol de Ventas + Rol de Exportación. Alguien que hace ventas y soporte tendría: Rol Base + Rol de Ventas + Rol de Servicio.
Las ventajas son significativas: no hay duplicación (cada privilegio está definido en un solo lugar), es fácil crear combinaciones sin crear nuevos roles, y los cambios se propagan automáticamente a todos los usuarios afectados.
La desventaja es que requiere más planificación upfront y mejor documentación. Si alguien mira la lista de roles de un usuario y ve cinco roles, necesita saber qué hace cada uno.
Mi recomendación
Para organizaciones pequeñas (menos de 50 usuarios) con perfiles simples, el enfoque monolítico puede funcionar bien. Es más simple y no vas a tener tantas combinaciones que gestionar.
Para organizaciones medianas o grandes, o para cualquier organización que espere crecer significativamente, invierte en el enfoque modular desde el principio. El trabajo extra de planificación se paga solo en mantenibilidad a largo plazo.
El proceso de crear un rol personalizado
Ya sea que estés creando un rol monolítico o un componente modular, el proceso debería ser sistemático.
Paso 1: Documenta los requisitos
Antes de tocar el sistema, siéntate a documentar exactamente qué necesita poder hacer el usuario con este rol. Y sé específico. "Acceso a cuentas" no es suficiente. ¿Puede crear cuentas? ¿Puede eliminarlas? ¿Puede ver todas las cuentas de la empresa o solo las de su equipo?
Una forma útil de estructurar esto es por entidad:
- Account: Read (BU), Write (User), Create (User), Delete (ninguno)
- Contact: Read (BU), Write (User), Create (User), Delete (User)
- Opportunity: Read (User), Write (User), Create (User), Delete (ninguno)
También documenta requisitos de privilegios misceláneos: ¿necesita exportar a Excel? ¿Necesita hacer merge de duplicados? ¿Necesita ejecutar flujos de trabajo?
Paso 2: Identifica un rol base
Rara vez tiene sentido empezar de cero. Busca un rol OOB o un rol existente que se parezca a lo que necesitas. Será tu punto de partida.
Si no hay nada parecido, considera usar Basic User como base mínima, ya que proporciona acceso básico al sistema.
Paso 3: Crea el rol
Copia el rol base con "Guardar como" y dale un nombre descriptivo. Por favor, no uses "Custom Role 1". Un buen nombre incluye:
- El nombre de tu organización o un prefijo que lo identifique como personalizado
- Una descripción clara de para qué es el rol
- Opcionalmente, alguna característica distintiva
Ejemplos de buenos nombres: "Contoso - Vendedor Regional", "ACME - Agente L1", "Custom - Solo Lectura Oportunidades".
Paso 4: Configura los privilegios
Ahora viene el trabajo técnico. Abre el rol y ve configurando privilegios entidad por entidad según tu documentación del Paso 1.
Un principio crítico aquí es el de mínimo privilegio: empieza con lo mínimo necesario y solo añade más si hay una necesidad demostrada. Es mucho más fácil responder a "necesito acceso a X" añadiendo un privilegio que darte cuenta después de que has dado demasiado acceso y tener que restringirlo.
Algunos puntos específicos a vigilar:
- No olvides Append/AppendTo para entidades que tienen relaciones. Si el usuario va a crear oportunidades asociadas a cuentas, necesita Append en Opportunity y AppendTo en Account.
- Read casi siempre debe estar al menos al mismo nivel que Write. No puedes editar lo que no puedes ver.
- Delete es peligroso. Piensa dos veces antes de otorgarlo. ¿Realmente necesitan eliminar, o pueden simplemente desactivar?
Paso 5: Prueba exhaustivamente
Este paso es crucial y frecuentemente ignorado. Antes de desplegar un rol a producción, debes probarlo.
El proceso ideal es:
Crea un usuario de prueba en el entorno. Puede ser un usuario ficticio o tu propia cuenta en un entorno de desarrollo.
Asigna SOLO el rol que estás probando a ese usuario. Esto es importante: si el usuario tiene otros roles, esos roles pueden estar supliendo permisos que tu nuevo rol no tiene, y no te darás cuenta del problema hasta que alguien use el rol en aislamiento.
Inicia sesión como ese usuario y verifica sistemáticamente cada escenario de uso. ¿Puede crear los registros que debería poder crear? ¿Puede verlos? ¿Puede editarlos? ¿Puede asociarlos a otros registros? ¿Puede asignarlos?
Documenta cualquier problema y ajusta el rol según sea necesario. Luego vuelve a probar.
Paso 6: Documenta el rol
Un rol sin documentación es una bomba de tiempo. Semanas o meses después, nadie recordará por qué se creó ni qué se supone que hace.
Como mínimo, documenta:
- Propósito: ¿para qué perfil de usuario se creó este rol?
- Entidades principales: ¿cuáles son las entidades clave que cubre?
- Limitaciones: ¿hay algo que intencionalmente NO puede hacer?
- Dependencias: ¿necesita combinarse con otros roles?
El lugar ideal para esta documentación es en la propia descripción del rol dentro de Dataverse, donde cualquiera que abra el rol puede verla.
Errores comunes que debes evitar
Después de años trabajando con sistemas de seguridad en Dataverse, estos son los errores que veo repetirse una y otra vez:
Dar Organization a todo "porque es más fácil". Sí, es más fácil configurar. Pero estás eliminando el propósito de tener seguridad. Cuando todos pueden ver todo, pierdes privacidad, pierdes control, y potencialmente violas regulaciones de protección de datos.
Olvidar probar las relaciones. Los privilegios Append y AppendTo son frecuentemente olvidados porque no son intuitivos. Y cuando los olvidas, los usuarios ven errores crípticos al intentar asociar registros.
No probar el rol en aislamiento. He visto roles que "funcionaban" solo porque el usuario también tenía otros roles que suplían los permisos faltantes. Cuando alguien nuevo recibe solo ese rol, todo falla.
Crear roles con nombres genéricos. "Custom Role 1" no le dice nada a nadie. Cuando tengas 20 roles, no recordarás cuál era cuál.
No documentar. Sin documentación, cada vez que alguien tiene una pregunta sobre un rol, hay que investigar manualmente privilegio por privilegio para entender qué hace.
Puntos clave
- El enfoque modular es más trabajo inicial pero mucho más mantenible a largo plazo
- Siempre empieza restrictivo y añade privilegios según necesidad demostrada
- Nunca olvides Append/AppendTo para entidades con relaciones
- Prueba cada rol en aislamiento con un usuario que solo tenga ese rol
- Documenta el propósito y limitaciones de cada rol
- Usa nombres descriptivos que indiquen claramente para qué es cada rol