Licencias de Dynamics 365 Finance & Operations: cómo dimensionarlas sin pagar de más
Finance, Supply Chain Management, Team Members, Operations Activity, dispositivos, base y attach: qué necesita realmente cada usuario y por qué los roles de seguridad determinan el consumo.
Licenciar Dynamics 365 Finance & Operations ya no consiste en contar usuarios del ERP y asignarles una categoría genérica. Microsoft relaciona el acceso efectivo con las funciones, privilegios y roles que tiene cada persona. Un permiso innecesario puede elevar el requisito de licencia, mientras que una licencia insuficiente puede dejar al usuario fuera del sistema cuando se aplique la validación.
La licencia no depende del cargo del usuario. Depende de lo que el sistema le permite hacer.
No basta con decidir que un director necesita una licencia completa y un administrativo una licencia limitada. Dos personas con el mismo puesto pueden ejecutar procesos distintos. Y dos usuarios con licencias diferentes pueden acabar teniendo los mismos permisos si los roles de seguridad se han construido sin control.
En Finance & Operations, los roles agrupan deberes, privilegios y puntos de entrada. Microsoft mapea esos objetos de seguridad a niveles de licencia. Por eso la estimación correcta empieza con responsabilidades, tareas y roles, no con una tabla aislada de precios.
Responsabilidad
Qué procesos ejecuta el usuario, qué decisiones toma, qué datos modifica y si actúa para sí mismo o en nombre de terceros.
Acceso efectivo
Qué funciones habilitan realmente sus roles, aunque el usuario no las utilice o ni siquiera sepa que dispone de ellas.
Licencia requerida
La aplicación o nivel de licencia necesario para cubrir todos los objetos de seguridad incluidos en los roles asignados.
Licencia asignada
La suscripción que se ha asignado en el centro de administración. Debe cubrir el requisito calculado por los roles.
Comprar licencias antes de limpiar los roles puede convertir una mala seguridad en un coste recurrente
Si un rol contiene funciones que nadie necesita, asignar más licencias resuelve el aviso de cumplimiento, pero no el problema de fondo. La secuencia correcta es analizar la diferencia entre licencia requerida y asignada, retirar permisos injustificados, validar que el usuario conserva las tareas necesarias y comprar o reasignar las licencias que sigan siendo necesarias.
Principales licencias para usuarios de Dynamics 365 Finance & Operations
La guía oficial distingue entre licencias de usuario con acceso completo, licencias adicionales de acceso limitado, licencias de dispositivo y licencias o capacidades a nivel de tenant. La elección concreta depende de las aplicaciones utilizadas y de las funciones asignadas.
| Licencia o modelo | Para qué tipo de usuario | Qué debe revisarse | Error frecuente |
|---|---|---|---|
| Dynamics 365 Finance | Usuarios que ejecutan funciones financieras completas, contabilidad, tesorería, presupuestos, activos, cierre o administración financiera. | Roles financieros, diseño de informes, aprobaciones y funciones que cruzan otras aplicaciones. | Asignarla por pertenecer al departamento, sin revisar la función real. |
| Dynamics 365 Finance Premium | Usuarios que necesitan capacidades premium de Finance, incluidas funciones avanzadas especificadas por Microsoft. | Qué usuarios consumen realmente funciones premium y qué capacidades están incluidas en la edición vigente. | Extender Premium a toda la población por una necesidad localizada. |
| Supply Chain Management | Usuarios con responsabilidades completas en compras, ventas, inventario, producción, planificación, almacenes, activos o cadena de suministro. | Diferencia entre perfiles operativos completos, actividades limitadas y dispositivos compartidos. | Licenciar individualmente tareas que se realizan exclusivamente en un dispositivo compartido elegible. |
| Supply Chain Management Premium | Usuarios que requieren las capacidades premium de Supply Chain Management publicadas en la guía vigente. | Qué roles y funciones justifican Premium y cómo se limita su asignación. | No diferenciar usuarios de configuración, planificación y operación diaria. |
| Operations – Activity | Usuarios nominales que necesitan más capacidades que Team Members, pero no todo el acceso de una aplicación completa. | Tareas y aprobaciones permitidas, especialmente las incluidas en el anexo de privilegios de actividad. | Suponer que cualquier aprobación queda cubierta por esta licencia. |
| Dynamics 365 Team Members | Usuarios nominales con lectura general y tareas limitadas aprobadas, como determinadas entradas, consultas, autoservicio o aprobaciones. | Que las acciones correspondan a los escenarios permitidos y, cuando aplique, se realicen para uso propio. | Tratar Team Members como un usuario completo barato. |
| Operations – Device | Un dispositivo dedicado y compartido utilizado por varias personas en escenarios permitidos de punto de venta, producción, almacén u operaciones. | Que el acceso se produzca desde el dispositivo licenciado y dentro de las capacidades autorizadas. | Usarla para empleados que trabajan también desde equipos personales o fuera del escenario del dispositivo. |
| Operations – Order Lines | Determinados escenarios de transacciones indirectas medidos por líneas de pedido y definidos por Microsoft. | Tipo de transacción, sistema origen, volumen y condiciones exactas de uso. | Pensar que cubre cualquier acceso por API, portal o aplicación externa. |
| Capacidades y licencias de tenant | Servicios o recursos que se licencian a nivel de organización, como capacidades adicionales o determinados productos. | Almacenamiento, transacciones, entornos, uso de datos y límites incluidos. | Revisar usuarios y olvidar capacidad, almacenamiento o servicios asociados. |
No existe una licencia llamada “usuario concurrente” para sustituir usuarios nominales
La guía antigua de esta página sugería valorar usuarios concurrentes frente a usuarios individuales. Ese planteamiento no corresponde al modelo actual de licencias de usuario de Dynamics 365. Las licencias de usuario se asignan a personas concretas. Los dispositivos compartidos tienen su propio modelo y solo encajan en escenarios definidos.
Cómo funciona el modelo base y attach
Cuando una misma persona necesita varias aplicaciones Dynamics 365 con acceso completo, no siempre se compran todas al precio base. Microsoft utiliza un modelo base y attach para aplicaciones compatibles. La primera aplicación debe ser la licencia base adecuada y las aplicaciones adicionales elegibles pueden asignarse como attach.
La primera aplicación completa del usuario
Cada usuario con acceso completo necesita una licencia base. Cuando utiliza varias aplicaciones, la base debe cumplir las reglas de precedencia y elegibilidad publicadas por Microsoft. No puede asignarse una licencia attach si el usuario no tiene una base que la admita.
Una aplicación adicional para el mismo usuario
La licencia attach ofrece las mismas capacidades centrales de la aplicación que su equivalente base y se diferencia por el precio y los requisitos de asignación. No añade por sí misma nuevas capacidades de plataforma a las incluidas con la base.
| Perfil | Necesidad | Enfoque a revisar |
|---|---|---|
| Responsable financiero | Funciones completas de Finance y tareas limitadas de cadena de suministro. | Una licencia completa de Finance puede incluir determinados derechos limitados en otras aplicaciones; revisar roles antes de añadir otra licencia completa. |
| Director de operaciones | Acceso completo a Supply Chain Management y capacidades financieras completas. | Revisar qué aplicación debe ser base y si Finance puede asignarse como attach elegible. |
| Usuario de varias áreas | Finance, Supply Chain, Project Operations u otras aplicaciones completas. | Aplicar la matriz de base y attach vigente para evitar duplicar licencias base. |
Attach no significa compartir una licencia entre aplicaciones o usuarios
La licencia attach pertenece al mismo usuario nominal que tiene la base. No puede utilizarse para cubrir a otra persona ni asignarse sin una base compatible. La elegibilidad, los precios y los mínimos de compra deben comprobarse en la guía y los Product Terms vigentes.
Team Members, Operations Activity o licencia completa: cómo evitar una clasificación demasiado simple
El volumen de usuarios adicionales suele ser muy superior al de usuarios centrales del ERP. Aquí se concentra gran parte de la optimización, pero también el riesgo de cumplimiento. La decisión no puede basarse solo en la frecuencia de uso: una persona que entra una vez al mes puede ejecutar una función que exija licencia completa.
Lectura y escenarios básicos definidos
Incluye lectura de datos de Dynamics 365 y determinadas tareas, como registro de tiempo o gastos, aprobaciones permitidas, requisiciones y autoservicio, según la aplicación y los límites publicados.
No cubre: cualquier modificación o proceso operativo por el mero hecho de ser ocasional.
Más capacidad sin llegar al acceso completo
Incluye los derechos de Team Members y capacidades adicionales limitadas en Finance, Supply Chain Management, Commerce, Human Resources y Project Operations.
Debe revisarse: cada tarea y aprobación, porque algunas exigen una licencia de aplicación completa.
Responsabilidad funcional completa
Necesaria cuando el usuario ejecuta funciones que exceden los escenarios limitados, diseña determinados informes o administra procesos completos de Finance, Supply Chain u otras aplicaciones.
Incluye: derechos de niveles inferiores en los términos definidos por la guía.
Preguntas para clasificar un usuario
¿Solo consulta información o también crea, modifica, aprueba y contabiliza?
¿La tarea se realiza para sí mismo o en nombre de otros usuarios, clientes o proveedores?
¿Gestiona una parte limitada o administra el proceso completo?
¿Diseña informes financieros o únicamente los consulta?
¿Sus roles contienen privilegios que no utiliza pero elevan la licencia?
¿Trabaja siempre desde un dispositivo compartido elegible o también desde equipos personales?
La validación de licencias convierte el diseño de roles en una prioridad operativa
Microsoft ha reforzado la visibilidad y la validación de licencias por usuario en las aplicaciones de finanzas y operaciones. Las organizaciones necesitan identificar diferencias entre permisos requeridos y licencias asignadas antes de que el acceso de usuarios pueda verse afectado.
Dónde comprobar licencias requeridas, asignadas y diferencias
Microsoft proporciona visibilidad desde el centro de administración de Power Platform y desde User security governance en Finance & Operations. Estas herramientas ayudan a localizar usuarios con licencias insuficientes y a comprender qué roles, deberes, privilegios o puntos de entrada generan el requisito.
La información debe interpretarse con la guía de licenciamiento vigente, los Product Terms y el diseño funcional del cliente. El informe calcula requisitos; no decide si un usuario necesita realmente conservar cada permiso.
Power Platform admin center
Ofrece una vista consolidada del consumo de licencias de las aplicaciones de finanzas y operaciones y permite comparar las licencias disponibles con las que requieren los usuarios.
User License Summary
Muestra el requisito por usuario y permite profundizar en los roles y objetos que provocan cada licencia. La disponibilidad depende de la versión y de la configuración de User security governance.
Vista por roles y objetos
Permite analizar si el requisito nace de un rol completo, un deber, un privilegio o un punto de entrada. Es clave para evitar retirar funciones necesarias de forma indiscriminada.
Microsoft 365 admin center
Es el entorno donde se asignan las licencias a los usuarios. Una corrección de roles en F&O y una asignación de licencia deben coordinarse para cerrar la diferencia.
| Situación detectada | Qué significa | Acción correcta |
|---|---|---|
| El usuario necesita una licencia superior a la asignada | Alguno de sus roles contiene funciones no cubiertas. | Comprobar si necesita el permiso. Si lo necesita, asignar la licencia; si no, corregir el rol. |
| La mayoría de usuarios de un rol requieren una licencia inesperada | El rol probablemente contiene un deber o privilegio sobredimensionado. | Analizar el objeto que eleva la licencia y separar responsabilidades si procede. |
| Usuario con licencia completa y casi sin uso | Puede existir una cuenta inactiva o un perfil que necesite acceso más limitado. | Revisar actividad, responsabilidad y roles antes de retirar la licencia. |
| El informe cambia después de una actualización | Pueden haberse actualizado mapeos, roles o capacidades. | Comparar versiones, revisar cambios y validar el impacto antes de actuar. |
Cómo preparar una revisión de licencias sin bloquear a los usuarios
La revisión debe combinar información contractual, datos del tenant, seguridad de F&O y validación funcional. Corregir cientos de roles directamente en producción es una mala estrategia. El análisis necesita prioridades, pruebas y responsables.
Inventariar contratos y licencias
Recopilar suscripciones base, attach, Activity, Team Members, dispositivos, fechas de renovación, cantidades, capacidades y cualquier condición particular del acuerdo.
Extraer usuarios y requisitos
Obtener usuarios activos, roles, licencias asignadas, licencias requeridas, diferencias y actividad. La foto debe incluir todas las entidades y entornos relevantes.
Clasificar por impacto
Separar usuarios sin licencia, licencias insuficientes, roles sobredimensionados, cuentas inactivas y oportunidades de base/attach. Priorizar perfiles críticos y grandes poblaciones.
Validar tareas con negocio
Confirmar qué hace cada perfil y si los permisos que elevan la licencia son necesarios. No retirar accesos basándose únicamente en que el usuario no los ha utilizado recientemente.
Rediseñar roles donde exista causa común
Cuando un privilegio afecta a muchos usuarios, corregir el rol suele ser más eficaz que gestionar excepciones individuales. Los cambios deben probarse con procesos completos.
Asignar o reasignar licencias
Comprar, cambiar o retirar licencias solo después de validar el modelo de acceso. Coordinar la administración de Microsoft 365 con los responsables de F&O.
Repetir informes y pruebas
Comprobar que las diferencias se han cerrado, que los usuarios conservan las tareas necesarias y que los cambios no han creado conflictos de segregación.
Activar gobierno continuo
Incorporar licencias a las altas, bajas, cambios de puesto, nuevas funcionalidades, modificaciones de roles, revisiones de seguridad y renovaciones contractuales.
Una API, un portal o una aplicación intermedia no eliminan automáticamente la obligación de licenciar
Microsoft denomina multiplexing al uso de hardware o software para agrupar conexiones, redirigir información o reducir el número de usuarios o dispositivos que acceden directamente a Dynamics 365. Introducir una capa intermedia no reduce por sí mismo las licencias necesarias.
Los usuarios o dispositivos internos que introducen, consultan o visualizan datos de Dynamics 365 directa o indirectamente deben estar correctamente licenciados, salvo que exista un derecho de acceso específico aplicable. El número de capas técnicas entre el ERP y la persona final no cambia esta regla.
Portal interno conectado al ERP
Si empleados o contratistas internos consultan o actualizan datos de Dynamics 365 a través del portal, hay que analizar sus derechos de uso. Ocultar la interfaz de F&O no convierte el acceso en gratuito.
Aplicación Power Apps
Power Apps puede acceder a tablas no restringidas según sus derechos, pero crear, actualizar o eliminar datos en tablas restringidas de Dynamics 365 requiere la licencia correspondiente de Dynamics 365.
Integración automatizada
Una cuenta técnica que agrupa operaciones de múltiples usuarios no elimina la necesidad de revisar a los usuarios finales que originan o consumen el proceso.
Operaciones indirectas elegibles
Operations – Order Lines puede cubrir determinados tipos de transacción indirecta. No es una licencia genérica para toda integración y debe evaluarse según los escenarios autorizados.
Automatizar no evita licencias; cambia la forma en que debe analizarse el proceso
Cada integración debe documentar quién inicia la operación, quién recibe el resultado, qué datos se consultan o modifican y qué derecho de acceso cubre el escenario. Esta revisión debe realizarse antes de diseñar portales, aplicaciones, agentes o flujos alrededor del ERP.
Proveedor, contratista, cliente o usuario externo no significan lo mismo a efectos de licencia
La guía de Microsoft define el acceso externo con condiciones concretas. Empleados, afiliados y determinados contratistas o agentes que trabajan para la organización se consideran usuarios internos y necesitan licencias. Un proveedor que ejecuta procesos internos en nombre de la empresa no se convierte automáticamente en usuario externo por utilizar un correo de otra compañía.
| Escenario | Análisis necesario | Riesgo habitual |
|---|---|---|
| Empleado | Licencia de usuario o acceso por dispositivo según su actividad. | Considerarlo cubierto por otro sistema o por una cuenta compartida. |
| Consultor o proveedor que opera procesos internos | Revisar si actúa como usuario interno según las condiciones de Microsoft y qué funciones ejecuta. | Interpretar que todo tercero es usuario externo sin licencia. |
| Cliente o proveedor que consulta un portal | Validar derechos de acceso externo, Power Pages y datos o procesos expuestos. | Dar acceso a la interfaz no permitida o ampliar funciones sin revisar licencias. |
| Operario en dispositivo compartido | Comprobar que el dispositivo y las tareas cumplen los escenarios de Operations – Device. | Permitir el uso desde otros equipos o conceder capacidades superiores. |
Qué encarece o pone en riesgo el licenciamiento de Dynamics 365 F&O
Los problemas rara vez proceden de una sola licencia mal asignada. Suelen nacer de procesos de alta deficientes, roles acumulativos, integraciones no analizadas y ausencia de gobierno.
Licenciar por departamento
Personas del mismo departamento pueden necesitar niveles distintos. La unidad correcta es la responsabilidad y el acceso efectivo.
Confundir uso ocasional con uso limitado
La frecuencia no determina la licencia. Una operación ejecutada una vez al año puede exigir una licencia completa.
Acumular roles tras cada cambio
El usuario conserva permisos de antiguos puestos, eleva su licencia y crea conflictos de segregación.
Comprar antes de analizar
Cerrar diferencias solo con nuevas licencias perpetúa roles sobredimensionados y costes que podrían evitarse.
Retirar permisos sin probar
Una limpieza precipitada puede bloquear cierres, aprobaciones, integraciones o tareas poco frecuentes pero críticas.
Ignorar base y attach
Comprar varias aplicaciones completas como bases para el mismo usuario puede incrementar el coste innecesariamente.
Usar cuentas compartidas
Dificultan la trazabilidad y no sustituyen las reglas de licenciamiento por usuario o dispositivo.
Olvidar integraciones y Power Platform
El acceso indirecto, las tablas restringidas y las aplicaciones intermedias pueden mantener requisitos de Dynamics 365.
Revisar solo en la renovación
Los roles cambian durante todo el año. Esperar a la renovación genera decisiones urgentes y con poca capacidad de prueba.
Cuándo revisar licencias para no descubrir el problema en la renovación
Una revisión anual puede servir para negociar cantidades, pero llega tarde para corregir roles, probar nuevos perfiles y cerrar diferencias de cumplimiento. El licenciamiento debe integrarse en los cambios que modifican usuarios, procesos y arquitectura.
La frecuencia no tiene que ser igual para todo. Los usuarios críticos, administradores, grandes poblaciones y roles que cambian con frecuencia necesitan seguimiento más cercano que perfiles estables y bien delimitados.
Antes de implantar o ampliar F&O
El diseño de licencias debe acompañar a los procesos y roles desde la fase de solución. Esperar al final puede obligar a rediseñar seguridad o aceptar un coste no previsto.
Después de una reorganización
Cambios de puesto, nuevas áreas, servicios compartidos y adquisiciones alteran responsabilidades. Añadir roles sin retirar los anteriores suele elevar licencias y conflictos.
Al incorporar nuevas funcionalidades
Nuevos módulos, agentes, integraciones, aplicaciones Power Platform o automatizaciones pueden cambiar los objetos de seguridad y los derechos de uso necesarios.
Antes de una renovación contractual
La revisión debe empezar con margen suficiente para analizar datos, validar con negocio, modificar roles, probar y ajustar cantidades. Hacerlo en la última semana reduce la decisión a comprar o asumir riesgo.
Después de actualizaciones relevantes
Los mapeos, capacidades e informes pueden evolucionar. Conviene comparar resultados y revisar cambios antes de concluir que todos los nuevos requisitos son errores.
Cuando aparecen diferencias de validación
No debe esperarse a que se bloquee el acceso. Los avisos deben activar un análisis coordinado entre administración de licencias, seguridad, responsables funcionales y soporte.
El indicador útil no es solo cuánto gastamos, sino cuánto acceso innecesario estamos financiando
Un cuadro de seguimiento debería combinar licencias compradas, asignadas y requeridas; usuarios inactivos; roles sobredimensionados; diferencias abiertas; aplicaciones base y attach; dispositivos; accesos indirectos y fecha de renovación. Así la organización puede distinguir ahorro real, riesgo de cumplimiento y decisiones pendientes.
Optimizar licencias sin revisar la segregación de funciones puede crear un problema mayor
Separar un rol para ajustar licencias puede cambiar la combinación de tareas de los usuarios. Del mismo modo, retirar un privilegio de un rol masivo puede reducir el requisito de licencia, pero también eliminar un control, una aprobación o una responsabilidad necesaria.
Licenciamiento, seguridad y control interno deben analizarse juntos. El modelo objetivo tiene que cubrir la función del usuario, respetar la segregación de responsabilidades y asignar la licencia que corresponde al acceso final.
Secuencia de decisión
Definir qué tareas debe ejecutar el perfil.
Comprobar que no concentra funciones incompatibles.
Diseñar o ajustar roles con mínimo privilegio.
Calcular el requisito de licencia resultante.
Asignar la licencia y validar el proceso completo.
Del inventario de licencias a un modelo sostenible de usuarios, roles y costes
Una revisión de licenciamiento útil no debe limitarse a comparar compras y usuarios. Ayesa puede combinar análisis contractual, informes de consumo, seguridad de Dynamics 365, procesos empresariales y validación con responsables funcionales.
El trabajo puede incluir identificación de diferencias, análisis de roles que elevan licencias, revisión de usuarios inactivos, base y attach, dispositivos, acceso indirecto, integraciones, Power Platform y relación con la segregación de funciones.
El objetivo es reducir exposición y coste evitable sin impedir que las personas ejecuten sus procesos. Una optimización correcta debe seguir funcionando después de una actualización, una reorganización o una renovación contractual.
Posibles líneas de trabajo
Inventario de licencias, contratos y renovaciones.
Análisis de licencias requeridas y asignadas.
Optimización de roles y privilegios.
Revisión de base, attach y usuarios adicionales.
Dispositivos, integraciones y acceso indirecto.
Pruebas, remediación y preparación para validación.
Gobierno de altas, bajas, roles y renovaciones.
Continúa la ruta de Dynamics 365 Finance & Operations
Consulta las páginas relacionadas con producto, migración, soporte y gobierno del ERP.
Dudas habituales sobre licencias de Dynamics 365 Finance & Operations
¿Dynamics 365 Finance & Operations se licencia por usuario?
Las principales aplicaciones y niveles de acceso se licencian mediante usuarios nominales o dispositivos dedicados, según el escenario. También existen capacidades y productos a nivel de tenant. No debe interpretarse como un modelo de usuarios concurrentes.
¿Qué determina la licencia que necesita un usuario?
El acceso efectivo concedido por sus roles, deberes, privilegios y puntos de entrada. El cargo, la frecuencia de acceso o el departamento no bastan para determinarla.
¿Qué diferencia hay entre base y attach?
La base es la primera aplicación completa del usuario. Las licencias attach permiten añadir aplicaciones elegibles al mismo usuario cuando dispone de una base compatible. Base y attach tienen las mismas capacidades centrales de la aplicación y se diferencian por precio y requisitos.
¿Team Members permite modificar cualquier información?
No. Team Members ofrece lectura y tareas limitadas dentro de escenarios definidos. No es una licencia completa de bajo coste y sus derechos deben contrastarse con la guía vigente.
¿Operations Activity cubre todas las aprobaciones?
No. Incluye determinados privilegios y aprobaciones, pero algunas operaciones requieren una licencia completa. La guía incorpora un anexo específico para los privilegios de aprobación de Activity.
¿Cuándo tiene sentido una licencia de dispositivo?
Cuando varias personas operan exclusivamente desde un dispositivo dedicado y compartido dentro de escenarios autorizados, como determinadas funciones de almacén, producción, tienda o punto de venta. No cubre cualquier acceso desde equipos personales.
¿Una integración evita licenciar a los usuarios?
No de forma general. El multiplexing no reduce automáticamente las licencias. Hay que revisar quién introduce, consulta o recibe datos y si existe un derecho específico, como determinados escenarios de Operations – Order Lines.
¿Power Apps puede sustituir una licencia de Dynamics 365?
Power Apps puede cubrir aplicaciones y tablas dentro de sus derechos, pero el acceso de creación, actualización o eliminación a tablas restringidas de Dynamics 365 exige licencias Dynamics 365 adecuadas. Cada arquitectura debe analizarse.
¿Los usuarios externos necesitan licencia?
Microsoft incluye determinados derechos de acceso externo, pero la definición excluye a empleados y a ciertos contratistas o agentes que actúan como usuarios internos. También existen limitaciones sobre interfaces y formas de acceso. Debe revisarse cada caso.
¿Cómo detecto usuarios con licencias insuficientes?
El centro de administración de Power Platform y User security governance ofrecen informes de consumo y requisitos. Permiten localizar diferencias entre la licencia requerida por los roles y la licencia asignada.
¿Debo comprar una licencia superior cuando aparece una diferencia?
Primero hay que comprobar si el usuario necesita la función que provoca el requisito. Si la necesita, debe asignarse la licencia. Si el permiso es innecesario, conviene corregir el rol y probar el proceso antes de comprar.
¿Las personalizaciones pueden cambiar el requisito de licencia?
Sí. Los nuevos objetos de seguridad y las personalizaciones deben mapearse al nivel de licencia que corresponda a su uso. Añadir funciones a un rol puede elevar el requisito de todos sus usuarios.
Fuentes de Microsoft para validar licencias y requisitos
Los precios, derechos, productos, mínimos de compra y condiciones pueden cambiar. Antes de contratar o modificar licencias debe consultarse la guía vigente, los Product Terms y la documentación del entorno.
¿Tus licencias reflejan lo que los usuarios necesitan o lo que sus roles permiten por accidente?
Cuéntanos qué aplicaciones utilizas, cuántos usuarios tienes y qué diferencias aparecen en los informes. Revisaremos contigo licencias, roles, acceso indirecto, dispositivos y oportunidades de optimización.
La mejor revisión no empieza comprando. Empieza comprobando qué acceso debe conservar cada perfil y qué licencia corresponde después.
¿Conectamos?
La tecnología bien aplicada suele facilitar las cosas. Si sospechas que también puede ser de ayuda para ti, concédenos la oportunidad de conocerte y demostrarte hasta qué punto es así.
Suscríbete a nuestra enews mensual, y no te pierdas los mejores contenidos sobre Microsoft Dymanics 365
Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ibermática SA; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: arco@ibermatica.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ibermática S.A.
¿Por qué Ayesa?
Somos uno de los principales implantadores de Microsoft, con casi 2000 clientes que han depositado su confianza en nosotros para la implantación de Dynamics 365, Business Central (NAV / Navision) y Dynamics 365 Finance & Operations (AX / Axapta). Además, destacamos en el despliegue de proyectos sobre AZURE y Microsoft 365. Nuestra experiencia en el campo de la inteligencia artificial y el uso de Copilot nos sitúa a la vanguardia de la innovación tecnológica.
Con una plantilla de más de 12.000 profesionales y una sólida presencia en 23 países, estamos comprometidos en ayudar a nuestros clientes a definir y aprovechar oportunidades en el nuevo contexto digital. Desde la tecnología hasta las personas, ofrecemos un enfoque integral que garantiza el éxito en cada proyecto.
- ÚLTIMAS ENTRADAS DEL BLOG -
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)