Las licencias son la primera barrera de seguridad, incluso antes que los roles. En esta lección aprenderás qué tipos de licencias existen y cómo afectan a lo que los usuarios pueden hacer.
Objetivos de aprendizaje
- Conocer los diferentes tipos de licencias disponibles para Power Platform y Dynamics 365
- Entender las capacidades y restricciones de la licencia Team Member
- Planificar correctamente la asignación de licencias
- Evitar errores comunes que causan bloqueos inesperados
La licencia como primera barrera
Hay algo que sorprende a mucha gente cuando empiezan a trabajar con seguridad en Power Platform: puedes tener un rol perfectamente configurado con todos los privilegios del mundo, y aun así el usuario no puede hacer nada. ¿Por qué? Porque no tiene la licencia correcta.
La licencia es la primera verificación que hace el sistema, antes incluso de mirar los roles de seguridad. Piensa en ella como el "ticket de entrada" al parque de atracciones. Sin ticket, no importa qué atracciones te gustaría montar; no pasas de la puerta.
Además, la licencia establece un "techo" de capacidades. Los roles de seguridad pueden restringir dentro de lo que la licencia permite, pero nunca ampliar más allá. Si tu licencia no permite crear oportunidades, ningún rol puede darte esa capacidad.
Los tipos de licencias
El ecosistema de licencias de Microsoft puede ser confuso porque hay muchas opciones y combinaciones. Vamos a simplificarlo centrándonos en las más relevantes para Dynamics 365 y Power Platform.
Licencias de Dynamics 365
Las aplicaciones de Dynamics 365 (Sales, Customer Service, Field Service, etc.) tienen sus propias licencias que dan acceso completo a esa aplicación específica. Si tienes Dynamics 365 Sales Enterprise, puedes hacer todo lo que la aplicación de ventas permite (crear leads, gestionar oportunidades, cerrar deals), limitado solo por tus roles de seguridad.
Estas licencias también incluyen acceso a Power Apps y Power Automate para uso relacionado con la aplicación, lo que se llama "seeded apps" o aplicaciones incluidas.
Power Apps y Power Automate
Si alguien no necesita una aplicación completa de Dynamics 365 pero sí necesita usar aplicaciones personalizadas en Dataverse, puede tener licencias específicas de Power Apps. Hay dos modalidades principales:
Power Apps Premium (anteriormente "per user") da acceso ilimitado a todas las aplicaciones y flujos que el usuario necesite, incluyendo conectores premium y Dataverse.
Power Apps per app da acceso a una aplicación específica. Más económico si el usuario solo necesita una o dos apps.
Team Member: la licencia que genera más confusión
Y luego está Team Member. Esta licencia merece atención especial porque es la fuente de innumerables tickets de soporte del tipo "no puedo crear registros y no sé por qué".
Team Member es una licencia económica diseñada para usuarios que necesitan acceso limitado al sistema. La idea es que en una organización típica, no todos necesitan capacidades completas. El CEO quizá solo quiere ver dashboards. Un empleado de almacén solo necesita registrar su tiempo. Un auditor solo necesita leer datos.
El problema es que las restricciones de Team Member son específicas y a veces no intuitivas:
Lectura: Puede leer prácticamente cualquier entidad sin restricciones significativas. Aquí no hay problema.
Escritura: Aquí viene lo complicado. Solo puede crear/editar un conjunto limitado de entidades específicas. No puede crear oportunidades, leads, cuentas, contactos principales... las entidades "de negocio" están vedadas para escritura.
Entidades permitidas: Sí puede escribir en entidades como actividades personales, notas, archivos adjuntos, entradas de tiempo, gastos, y un pequeño conjunto de otras. También puede escribir en entidades personalizadas, pero con un límite de 15 entidades personalizadas.
Este límite de 15 entidades personalizadas es particularmente traicionero. Si tienes 20 entidades personalizadas y un usuario con Team Member intenta escribir en ellas, en algún momento empezará a recibir errores aparentemente aleatorios porque ha alcanzado su límite.
Errores comunes y cómo evitarlos
El usuario "debería poder hacer X pero no puede"
Cuando diagnostiques este problema, el primer paso siempre debería ser verificar la licencia. ¿Tiene una licencia apropiada? ¿Es Team Member intentando crear una oportunidad? Si es así, ahí está tu respuesta: la licencia no lo permite.
Asumir que Team Member es suficiente
Es tentador asignar Team Member a todos los usuarios "normales" para ahorrar costes. Funciona hasta que no funciona. Alguien necesita crear un registro, no puede, y tienes un problema de negocio.
Antes de asignar Team Member, verifica exactamente qué necesita hacer el usuario. Si su trabajo requiere crear o editar registros de negocio principales, Team Member no es la licencia correcta.
El cambio de licencia que "no hace nada"
A veces cambias la licencia de un usuario y parece que no pasa nada. Esto puede ser el caché: el sistema sigue usando los permisos cacheados de la licencia anterior. Pide al usuario que cierre sesión completamente y vuelva a entrar.
Planificación de licencias
Una buena práctica es planificar las licencias antes de configurar roles de seguridad, no después. El flujo debería ser:
- Identificar qué perfiles de usuario tienes (vendedor, agente de soporte, gerente, etc.)
- Para cada perfil, determinar qué necesitan hacer (crear oportunidades, gestionar casos, solo leer...)
- Elegir la licencia apropiada para cada perfil
- Luego configurar roles de seguridad dentro de lo que la licencia permite
Hacerlo al revés (configurar primero los roles y después preocuparse por licencias) lleva a descubrir a última hora que la licencia elegida no soporta lo que configuraste.
Puntos clave
- La licencia es el primer filtro de seguridad - sin licencia apropiada, los roles no importan
- Team Member tiene lectura amplia pero escritura muy restringida
- El límite de 15 entidades personalizadas en Team Member causa problemas inesperados
- Verifica siempre la licencia como primer paso de troubleshooting
- Planifica licencias antes de configurar roles de seguridad