Dynamics 365 F&O: estado y guía práctica de “license enforcement”

Microsoft activará controles de licenciamiento para usuarios de Dynamics 365 Finance & Operations (F&O). Hoy existen reportes nuevos y cambios en cómo se calcula la licencia requerida por usuario; aún hay inconsistencias, por lo que es clave revisar y validar antes de comprar licencias adicionales.

Queremos guiarle de forma clara y sencilla acerca de qué está pasando con el licenciamiento por usuario en Dynamics 365 Finance & Operations (F&O), cómo leer los reportes nuevos, qué errores conocidos existen y qué pasos prácticos seguir antes de comprar licencias adicionales.

Fechas clave

• 1 de septiembre de 2025: comienzan advertencias in-app para usuarios sin la licencia adecuada.
• 1 de noviembre de 2025: inicia la aplicación estricta

Solicite nuestra asesoría en licenciamiento Ahora

Ahora el cálculo “oficial” de licencias se realizará a través del PPAC “Power Platform Admin Center”. El licenciamiento, ya no solo será calculado por menú; ahora es a nivel de objeto.

• Objetos que ahora cuentan para la licencia:
• Menu item (Display / Action / Output)
• Data entity
• Data entity method
• Service operation
  Regla general: accesos solo lectura suelen mapear a Team Members; mantener/configurar datos suele requerir Finance o Supply Chain Management (SCM).
• Cálculo “legacy” deprecado.

El cálculo “legacy” era el mecanismo anterior que usaba Dynamics 365 Finance & Operations para determinar qué licencia necesitaba cada usuario según su seguridad.

 
Se quitaron las columnas de “License” en Assign roles to user y View permissions de la Seguridad. Estas cifras a veces eran erróneas, no siempre estaba alineado con la guía oficial de licenciamiento, por lo que se consideró no ser mostradas ahora.

• Reunir y preparar los datos
  Exportar un CSV de PPAC “Power Platform Admin Center “/LCS y realice un cruce con el inventario actual de licencias de M365. Unifique todo en una sola vista donde pueda comparar lo requerido versus lo asignado.
• Diagnostique y clasifique usuarios
  Con esa vista, segmente a todos en cuatro grupos: sin licencia, licencia equivocada, base correcta, pero falta attach, y correctos. Así prioriza sus acciones por dónde actuar primero.
• Detecte falsos positivos
  Para los casos en donde se tengan dudas (usuarios que deberían leer, pero aparecen como “operación”), revise el License usage summary en F&O para ver qué rol/privilegio/objeto eleva la licencia y si hay permisos de Write no intencionales.
• Corrija la seguridad antes de comprar
  Quite roles innecesarios, estandarice roles personalizados y sustituya privilegios que traen “Write” por versiones solo lectura. Esto suele bajar el requerimiento de licencia a lo realmente necesario.
• Asigne licencias con criterio (Base/Attach)
  Escoja la base según el requerimiento más alto del usuario y agregue Attach donde haga falta. Si el reporte muestra “Commerce o Finance o SCM”, elige una SKU que cubra (no todas).
• Verifique y cierre brechas
  Tras los cambios, realice una revalidación cuando se refresquen los reportes y confirme que los conteos bajaron (sin licencia, mal licenciados, etc.).
• Gobernanza continua
  Defina responsables, una cadencia de revisión (quincenal/mensual), auditorías trimestrales de roles y privilegios con el fin de evitar regresiones.

• PPAC: Power Platform Admin Center (fuente oficial del cálculo).
• Team Members: licencia para escenarios de lectura y tareas ligeras.
• Base / Attach: combinación de licencias principales y complementarias por usuario.
• Entitled / Not entitled: objetos cubiertos / no cubiertos por una SKU.
• CUD: Create/Update/Delete (acciones que elevan la licencia).

El informe muestra, desde lo más amplio a lo más específico, quién necesita qué licencia y por qué. Úselo como “embudo”: comience por usuario, baje a roles y, si es necesario, llegue a privilegios/objetos.

1. User licenses: es la visión macro. Indica cuántas licencias exige cada usuario y cuántos objetos quedan “Not entitled” por cada SKU. Sirve para dimensionar el problema (quién está corto y en qué familia de licencias).
2. User role licenses: explica qué rol(es) están elevando el requerimiento de ese usuario. Si ve una SKU enumerado dos veces, suele ser un efecto del dato generado; enfóquese en la necesidad real (la cantidad que pide).
3. Role / Duty / Privilege licenses: A nivel de rol (o duty/privilegio) verifica si una SKU cubre ese rol (cuando Not entitled = 0). Si un rol “solo lectura” no cae en Team Members, probablemente arrastra algún permiso de escritura en sus privilegios; ahí está la pista para ajustarlo.
4. Cómo usarlo en conjunto: detecte al usuario con brecha en User licenses, identifica el rol causante en User role licenses y confirma en Role/Duty/Privilege si una SKU lo cubre o si hay que corregir permisos (quitar escrituras no deseadas) antes de decidir cambios de licencia.

¿Debo comprar más licencias ya?
No a ciegas. Primero limpie seguridad, valide “Base/Attach” y revise tras el refresco.

¿Por qué mis números no cambian al instante?
El cálculo se refresca cada ~8 h. No hay botón de refresco manual.

¿Qué hago si un rol estándar “solo lectura” pide más que Team Members?
Probablemente incluya “Write” en algún objeto. Duplique el privilegio, deja solo lectura y reemplaza.

Veo “Commerce o Finance o SCM” en el reporte. ¿Compro las tres?
No. Significa que cualquiera de esas Base puede cubrir ese rol. Elige una.

¿Dónde quedó la columna “License” en Seguridad?
Fue retirada (cálculo legacy deprecado). Usa PPAC/LCS + “License usage summary”.

• PPAC: Power Platform Admin Center (fuente oficial del cálculo).
• Team Members: licencia para escenarios de lectura y tareas ligeras.
• Base / Attach: combinación de licencias principales y complementarias por usuario.
• Entitled / Not entitled: objetos cubiertos / no cubiertos por una SKU.
• CUD: Create/Update/Delete (acciones que elevan la licencia).

Solicite nuestra asesoría en licenciamiento Ahora