Power Platform es fácil de adoptar — demasiado fácil, en algunos casos. Cualquier empleado con una licencia de Microsoft 365 puede crear un flujo de Power Automate o una app básica de Power Apps sin pedir permiso a nadie. Eso es una ventaja enorme para la productividad y un riesgo enorme si nadie supervisa lo que se construye.
Lo que pasa cuando nadie administra la plataforma
He visto este escenario en varias empresas: un empleado motivado empieza a crear apps y flujos. Resuelve problemas reales y la empresa se beneficia. Pero nadie documenta qué hizo, nadie revisa la seguridad, y todo corre bajo su cuenta personal con sus conexiones personales. Cuando ese empleado cambia de departamento o deja la empresa, sus flujos siguen funcionando... hasta que un día dejan de hacerlo. Y nadie sabe cómo arreglarlos porque nadie sabe cómo están hechos ni qué conexiones usan.
No es un escenario hipotético. Es lo que encuentro en la mayoría de empresas medianas que llevan más de un año con Power Platform sin gobernanza.
¿Qué hace un administrador de Power Platform?
No es lo mismo que un desarrollador. Un administrador de Power Platform se encarga de la plataforma en sí, no de construir apps individuales. Su trabajo incluye: gestionar entornos (desarrollo, test, producción), configurar y mantener políticas de DLP (Data Loss Prevention) para controlar qué conectores pueden usarse dónde, supervisar qué apps y flujos existen en el tenant, gestionar el ciclo de vida de las soluciones (ALM), asegurar que las conexiones críticas no dependen de cuentas personales, y ser el punto de contacto cuando algo se rompe o cuando alguien necesita algo que las políticas no permiten.
También es quien revisa las apps que los citizen developers crean antes de que pasen a producción, quien forma a los nuevos usuarios, y quien decide cuándo una necesidad requiere un desarrollador profesional en vez de un citizen developer.
El problema de las conexiones personales
Este es probablemente el riesgo operativo más concreto y menos visible. En Power Platform, los flujos de Power Automate usan conexiones — credenciales que enlazan el flujo con un servicio (Outlook, SharePoint, Dataverse, un sistema externo). Por defecto, esas conexiones se crean con la cuenta del usuario que construyó el flujo.
Si ese usuario deja la empresa y su cuenta se desactiva, todas las conexiones asociadas dejan de funcionar. Y con ellas, todos los flujos que las usaban. Si esos flujos eran críticos para la operativa — envío de notificaciones, procesamiento de pedidos, sincronización de datos — el impacto es inmediato.
Un administrador evita esto usando cuentas de servicio para las conexiones críticas, configurando connection references en las soluciones, y manteniendo un registro de qué conexiones usan los flujos importantes.
¿Hace falta un equipo dedicado?
No necesariamente. En empresas medianas, el rol de administrador puede ser una persona — incluso a tiempo parcial si el volumen de apps es bajo. Lo importante es que exista alguien con nombre y apellidos que sea responsable de la plataforma, que tenga acceso de administrador al tenant, y que dedique tiempo de forma regular a revisar el estado de la plataforma.
Otra opción, y es una de las formas en que trabajo con mis clientes, es externalizar la administración. Yo administro la plataforma de forma continua: gestiono los entornos, reviso las políticas, superviso lo que se crea, y estoy disponible cuando surge algo que requiere intervención. El cliente tiene la plataforma gobernada sin necesidad de contratar un perfil dedicado a tiempo completo.
El coste de no tener administrador
El coste no aparece en una factura — aparece en forma de flujos rotos que nadie sabe arreglar, datos corporativos moviéndose a servicios externos sin control, apps duplicadas que hacen lo mismo de formas distintas, y un tenant donde nadie sabe qué hay ni quién lo mantiene. Limpiar ese desorden después siempre cuesta más que haberlo prevenido desde el principio.