Actualización Importante sobre el Licenciamiento en Power Automate

En los últimos meses, hemos recibido noticias importantes sobre los cambios en el licenciamiento de Power Automate por parte de Microsoft. Estos cambios tienen como objetivo garantizar un uso adecuado de las licencias en la plataforma. En este artículo, intentaré desgranar los detalles y las implicaciones de estos cambios para que todo aquel que pueda verse afectado, actúe cuanto antes.

Control en el licenciamiento

Microsoft está tomando medidas para hacer cumplir el licenciamiento en Power Automate. Esto significa que los flujos que no cumplan con los requisitos de licencia podrían ser desactivados. Es muy importante entender estos cambios para evitar interrupciones en los flujos que tengamos trabajando.

Requisitos de Licencia

Un flujo de Power Automate debe tener una licencia "correcta" para funcionar sin problemas. Si el propietario de un flujo tiene una licencia "correcta", no habrá problemas de licenciamiento. Las licencias "correctas" pueden incluir:

• Licencia de Dynamics 365.
• Licencia de Power Automate por Usuario.

Sin embargo, hay situaciones en las que se requerirá una licencia adicional de Power Automate por flujo (las licencias caras, sí):

• Si el propietario del flujo tiene una Licencia de Power Apps.
• Si el propietario ya no tiene una licencia (por ejemplo, si tenía una licencia de prueba).
• Si el propietario ya no es parte de la organización.
• Si el propietario es un "Service Principal" u otro tipo de usuario no interactivo.

Quiero pararme en este último punto ya que me parece un cambio con un gran impacto. Muchos compañeros tienen como propietarios de los flujos en entornos productivos a un Service Principal.

Hay varios motivos por los cuales se hace de esta manera, pero entre ellos está la mejora en el ciclo de vida de los flujos, la seguridad de no utilizar un usuario nominal etc... Luego otra gran ventaja es que, aunque estos flujos perdían capacidad, no era necesario licenciarlos. Siempre fue bastante raro el hecho no de tener que licenciar este tipo de flujos, pero parece que finalmente Microsoft ha puesto medidas al darse cuenta del uso de esta práctica.

Excepciones Importantes

Hay ciertas situaciones en las que un flujo no requerirá una licencia adicional, incluso si cumple con los requisitos anteriores. Esto incluye flujos que:

• Interactúan con aplicaciones Dynamics.
• Están relacionados con entidades Dynamics (Caso, oportunidad, etc..).
• Utilizan la misma fuente de datos que las aplicaciones.
• Son iniciados o solicitados por aplicaciones Canvas.
• Operan "en contexto" de una aplicación

¿Qué significa que un flujo de Power Automate está "en contexto" de una aplicación?

Cuando decimos que un flujo está "en el contexto de una aplicación", significa que ese flujo está directamente vinculado y depende del funcionamiento y uso de una aplicación específica. En otras palabras, el flujo de trabajo está diseñado para ser utilizado en combinación con una determinada aplicación y su funcionalidad. La aplicación en cuestión puede ser una aplicación Dynamics, una aplicación Power App (Canvas o Model Driven), o incluso una aplicación de terceros.

Esta relación contextual es relevante en el contexto de los cambios de licenciamiento. Microsoft ha establecido ciertas exclusiones en las que los flujos pueden no requerir una licencia adicional, y una de esas exclusiones es cuando el flujo se encuentra "en el contexto de una aplicación". Esto significa que, si el flujo está diseñado para ser utilizado específicamente con una aplicación que está siendo licenciada correctamente, entonces el flujo no necesitaría una licencia adicional.

Pasos a seguir para realizar la asociación Flujo-Aplicación:
Si teneis flujos que necesitan ser asociados, hay acciones concretas que podemos hacer:

1. Identificar los flujos que necesitan asociación. Microsoft ha proporcionado un script de PowerShell llamado "Get-AdminFlowAtRiskOfSuspension" para ayudar con esto.Si quereis descargaros en un CSV los flujos afectados podeis probar con esto: Get-AdminFlowAtRiskOfSuspension -EnvironmentName <ENV_NAME> -ApiVersion '2016-11-01' | Export-Csv -Path suspensionList.csv -NoTypeInformation. Para los que no esten muy familiarizados con PowerShell, desde el centro de administración (y en versión preliminar) tenemos una herramienta que detacta los entornos que estan en conflicto. La ruta para utilizar esta herramienta es: Licencias (versión preliminar) | Centro de administración de Power Platform (microsoft.com)
2. Asociamos los flujos con una aplicación en el mismo entorno. Esto se puede hacer a través de la interfaz de usuario o mediante un script de PowerShell. Aquí os dejo el Link de como se hace.
3. Aseguraros de que la aplicación asociada se esté utilizando. Si no se utiliza, los flujos podrían seguir siendo considerados no compatibles y ser desactivados después de un período de gracia.

Plazos Importantes

A partir de agosto de 2023, los propietarios de flujos creados antes de esa fecha y que no estén correctamente licenciados recibirán notificaciones. Los propietarios tendrán un período de tres meses para realizar los cambios necesarios y solucionar cualquier problema de licenciamiento. Si los flujos no están correctamente licenciados después de este período de gracia, serán desactivados.
Los flujos creados después de la fecha límite no podrán ser activados si no cumplen con los requisitos de licencia.