Cuenta de servicio o entidad de servicio para flujos de Power Automate en producción: guía de decisión basada en la documentación de Microsoft.
Cuando un flujo se ejecuta en producción, la elección de la identidad subyacente determina si sigue funcionando incluso cuando una compañera está enferma, caduca una contraseña o alguien deja la empresa. Precisamente aquí surge una y otra vez la misma pregunta en Power Automate: ¿debe ejecutarse un flujo bajo una cuenta de servicio clásica, es decir, una cuenta de usuario compartida, o bajo una entidad de servicio, es decir, una identidad independiente y no humana en Microsoft Entra ID?
La respuesta breve de la documentación oficial es clara: Microsoft recomienda la entidad de servicio para flujos de producción críticos para el negocio y no clasifica explícitamente la cuenta de servicio clásica como práctica recomendada. Aun así, merece la pena examinar de cerca ambos modelos, ya que funcionan técnicamente de forma distinta y conllevan requisitos diferentes.
Según la documentación de Microsoft sobre licencias de Power Automate una cuenta de servicio es una cuenta de usuario de Microsoft Entra completamente normal que se reutiliza para representar una entidad no humana, como una aplicación o un servicio. En la práctica, esto significa que un equipo crea una cuenta como flow-produccion@empresa.es, comparte la contraseña con varias compañeras y compañeros, y esta cuenta pasa a ser propietaria de los flujos de producción.
Microsoft señala directamente el problema: si varias personas tienen acceso a la misma cuenta, resulta casi imposible saber quién realizó qué cambio en un flujo. A esto se suma la gestión de contraseñas como tema recurrente, por ejemplo con cambios de contraseña forzados o inicios de sesión multifactor. Por ello, Microsoft recomienda explícitamente revisar periódicamente los permisos de las cuentas de servicio existentes, mantener el círculo de personas con acceso lo más reducido posible y usar cuentas separadas para escenarios distintos con el fin de reducir la superficie de ataque. En algunos casos se utiliza una cuenta de servicio para hacer que un flujo sea independiente de su creador original. Pero para ese propósito concreto, Microsoft recomienda explícitamente cambiar a una entidad de servicio.
Según la documentación de Microsoft sobre la compatibilidad con flujos propiedad de una entidad de servicio una entidad de servicio es una identidad de seguridad no humana que representa una aplicación o un servicio y puede poseer y administrar recursos de forma independiente en Azure y en Power Platform. Técnicamente, se basa en un registro de aplicación de Microsoft Entra. Para que una entidad de servicio pueda ser propietaria de flujos en Power Platform, primero debe crearse un llamado usuario de aplicación, ya sea a través del centro de administración de Power Platform o mediante la API.
Una vez configurado este usuario de aplicación, se le puede transferir la propiedad de un flujo en la nube: en el flujo, abres la sección Detalles, seleccionas Editar y sustituyes al propietario por el nombre del usuario de aplicación. Importante: según la documentación, una entidad de servicio no puede convertirse en copropietaria de un flujo, sino únicamente en propietaria exclusiva. En un flujo fuera de una solución, además, todas las conexiones utilizadas deben compartirse explícitamente con el usuario de aplicación; en un flujo de solución, este paso no es necesario.
Para el día a día, la decisión puede basarse en criterios claros, tal y como también describe la documentación de Microsoft sobre el acceso a los flujos de Power Automate:
Una entidad de servicio que es propietaria de un flujo se considera en Power Automate un usuario de aplicación no interactivo y, por tanto, no puede recibir una licencia de usuario habitual. En su lugar, se aplican límites de solicitudes propios y sin licencia, y en cuanto el flujo utiliza conectores premium, necesita una licencia de proceso de Power Automate o una licencia por flujo, o bien la pertenencia a un grupo de flujos con la licencia correspondiente.
En cambio, para una cuenta de servicio clásica se aplica la lógica de licencias habitual para cuentas de usuario, complementada con una regla especial contra el llamado multiplexado: si varias personas comparten las credenciales de una cuenta de servicio y el flujo usa funciones premium, la documentación recomienda una licencia de proceso para el flujo en cuanto muchas personas distintas usen la cuenta, para que los nuevos usuarios que se añadan cumplan automáticamente con las licencias. No hay que confundir la cuenta de servicio con las cuentas de usuario no interactivas que Dataverse prevé para procesos en segundo plano, como las migraciones de datos: de estas se permiten un máximo de siete por inquilino, y Power Automate en sí aún no admite este tipo de cuenta especial como propietaria de un flujo, según la documentación.
Quien venga del mundo de Azure pensará rápidamente, para identidades no humanas, en las identidades administradas, es decir, identidades asignadas por el sistema o por el usuario que hacen completamente innecesarias las credenciales. Sin embargo, para los flujos en la nube de Power Automate este concepto no es, por ahora, una opción directa: las identidades administradas están ancladas sobre todo en Azure Logic Apps, donde ciertos conectores integrados y administrados, como Azure Key Vault, Azure Blob Storage o Azure SQL, pueden autenticarse a través de ellas. En el propio Power Automate, la entidad de servicio asume la tarea comparable de dar a un flujo una identidad estable, independiente de personas concretas. Quien opere flujos y Logic Apps en paralelo debería tener presente esta diferencia en lugar de equiparar mentalmente ambos conceptos.
El cambio se realiza en tres pasos: primero, creas un registro de aplicación en Microsoft Entra ID y, a partir de él, creas un usuario de aplicación en Power Platform. A continuación, compartes explícitamente con este usuario de aplicación todas las conexiones que utiliza el flujo, salvo que se trate de un flujo de solución. Por último, cambias en el flujo el propietario al nuevo usuario de aplicación y vuelves a activar el flujo. Reserva para este último paso una breve prueba antes de desactivar la cuenta de servicio anterior, para que los procesos productivos no se queden sin efecto.
Quien no quiera llevar a cabo por su cuenta la migración de varios flujos de producción de cuentas de servicio a entidades de servicio encontrará apoyo en la oferta de Power Automate de NordFlux, desde la configuración del registro de aplicación hasta la protección de la estructura de licencias y permisos. Así conservas el control sobre quién posee y opera cada automatización, incluso a medida que crece tu panorama de flujos.
No está prohibida, pero Microsoft no la clasifica explícitamente como práctica recomendada. Para flujos críticos para la empresa o de larga duración, la documentación recomienda claramente en su lugar la entidad de servicio, porque no depende de personas concretas ni de contraseñas compartidas.
No. Según la documentación, un usuario de aplicación de entidad de servicio solo puede ser propietario exclusivo de un flujo, nunca copropietario. Por eso ni siquiera aparece en el cuadro de diálogo de edición de copropietarios.
Una entidad de servicio es un usuario de aplicación no interactivo y, por tanto, no puede recibir una licencia de usuario habitual. En cuanto el flujo utiliza conectores premium, necesita en su lugar una licencia de proceso de Power Automate o una licencia por flujo, o la pertenencia a un grupo de flujos con la licencia adecuada.
No directamente para poseer un flujo en la nube. Las identidades administradas son ante todo un concepto de Azure Logic Apps para la autenticación frente a determinados recursos de Azure. En Power Automate, la entidad de servicio asume el papel comparable de una identidad de flujo estable y no humana.
Las conexiones no pasan automáticamente al nuevo propietario. Si se trata de un flujo fuera de una solución, debes además compartir explícitamente todas las conexiones utilizadas con el nuevo usuario de aplicación de la entidad de servicio; de lo contrario, la ejecución fallará. En un flujo de solución, este paso no es necesario, según la documentación.
Fundador de NordFlux. Siete años de experiencia, desde la web y el SEO hasta la automatización a escala de grupo, hoy de forma pragmática para las pymes y con soberanía de datos alemana.
Certificaciones
Tres palancas para flujos de Power Automate más rápidos: paralelismo dirigido, menos acciones y la elección correcta de conector, según la documentación de Microsoft.
Cómo respaldar y restaurar de forma fiable los flujos de Power Automate mediante la exportación de soluciones, según la documentación de Microsoft.
La elección entre cuenta de servicio y entidad de servicio determina los costes de licencia, los permisos y la resiliencia de los flujos en producción. NordFlux le asesora de forma neutral sobre la identidad adecuada para sus procesos críticos y acompaña el cambio cuando tiene sentido realizarlo.
