Transferir de forma limpia los flujos, las Power Apps y las conexiones al salir un empleado: la checklist de Power Platform para antes y después.
Cuando una empleada o un empleado se despide, la mayoría de los procesos de offboarding para el portátil, el buzón de correo y la tarjeta de acceso funcionan sin problemas. Lo que casi siempre se pasa por alto: los flujos, las Power Apps y las conexiones que esa persona creó en la Power Platform. Un flujo que cada mañana archiva facturas de un buzón en SharePoint no se da cuenta de inmediato de que su propietario ya no existe. Simplemente sigue funcionando hasta que una conexión caduca o se retira una licencia, y entonces todo el equipo se encuentra de repente con un proceso detenido sin explicación alguna.
Esta checklist está pensada como un lead asset: un documento que simplemente repasas la próxima vez que alguien se marche, en lugar de tener que pensar cada vez dónde quedan huellas de una persona en toda la Power Platform. Complementa nuestro artículo sobre Solutions in Power Automate, que explica por qué solo los flujos dentro de una solución pueden transferirse realmente de forma limpia. Aquí se trata del enfoque preventivo: qué comprobar en concreto antes, durante y después del último día laboral para que tus trabajadores digitales sigan funcionando, sin importar quién deje la empresa.
En la mayoría de las empresas, los flujos y las Power Apps no están registrados en ningún inventario central. Surgen de forma descentralizada, a menudo creados por una sola persona que quería automatizar una tarea recurrente. Precisamente eso es lo que los hace invisibles durante el offboarding: nadie en TI sabe que ese flujo existe, hasta que falla de repente tras la salida de quien lo creó.
Según la documentación oficial sobre el Cambio de propietario de un flujo en la nube, al crear un flujo, la persona que lo crea se convierte automáticamente en su propietario. Este rol determina los derechos de edición, los recursos compartidos, el historial de ejecución y, en algunos casos, incluso la licencia utilizada. Si esta persona deja la empresa sin una transferencia previa, el flujo se convierte en lo que Microsoft llama un flujo huérfano: una automatización sin propietario válido, cuyas conexiones pueden fallar en cualquier momento.
El principio más importante primero: todo lo que se pueda resolver antes de la salida es más sencillo que todo lo que haya que recuperar después. Mientras la persona aún tenga acceso, puedes trabajar junto a ella en lugar de tener que reconstruir después, como administrador, lo que realmente existe.
No todas las salidas dejan suficiente margen para resolverlo todo con antelación. Si la persona ya se ha marchado, necesitas la perspectiva de administrador.
Get-AdminFlow y Set-AdminFlowOwnerRole, en lugar de hacer clic en cada flujo por separado.Un malentendido frecuente es pensar que un flujo se detiene de inmediato cuando su propietario deja la empresa. En realidad, según la documentación sobre los flujos de equipo, un flujo compartido simplemente sigue funcionando por ahora, mientras tenga un propietario activo, como un copropietario. Solo cuando ya no existe ningún propietario activo, una transferencia se vuelve obligatoria.
La cosa se vuelve más crítica con la licencia. Según las preguntas frecuentes sobre licencias de Power Automate, un flujo premium cuyo propietario ya no tiene una licencia premium válida se degrada primero a un rendimiento menor. Se notifica a todos los propietarios, y si la situación no se resuelve, Power Automate desactiva por completo el flujo transcurridos 14 días. En la práctica, esas dos semanas son la ventana real de tiempo de la que dispones para una transferencia ordenada, antes de que una automatización en producción falle sin previo aviso.
La prevención más fiable no es en absoluto una acción de offboarding, sino una regla que ya se aplica al construir un flujo: cada flujo y cada app usados en producción reciben desde el principio al menos una segunda persona como copropietaria. Así, cuando alguien se marcha de verdad, solo queda el paso de retirar al propietario original, en lugar de tener que buscar uno nuevo bajo presión de tiempo. Quien combine esta regla con una estructura de gobernanza ligera, como describe nuestro artículo sobre CoE light para 30 empleados y además limite el acceso a grupos de conectores sensibles mediante Políticas DLP para principiantes, reduce claramente el riesgo de un flujo huérfano desde el principio.
Si no quieres mantener esta checklist manualmente, sino anclarla de forma fija como parte de tu propio proceso de offboarding, encontrarás en la consultoría de Power Automate de NordFlux el apoyo para establecer desde el principio, de forma limpia, la gobernanza y la prevención. Así mantienes el control sobre tus automatizaciones, incluso cuando los equipos cambian.
Un flujo sin copropietario todavía tiene un propietario válido y activo y sigue funcionando con normalidad. Solo cuando ese único propietario deja la organización y nadie asume el rol, el flujo se considera huérfano, es decir, sin propietario válido. Precisamente por eso un copropietario es la prevención más sencilla: evita que un flujo llegue siquiera a ese estado huérfano.
No, no directamente. Según la documentación, un administrador primero debe añadirse a sí mismo como propietario o copropietario antes de poder realizar cambios en un flujo ajeno. En el Power Platform Admin Center esto se hace mediante la función Compartir en la página de detalle del flujo correspondiente, donde introduces tu propio nombre como nuevo propietario y guardas el cambio.
A diferencia de los flujos independientes, los flujos compatibles con soluciones pueden reasignarse directamente a una nueva persona desde la vista de edición, sin exportar ni importar. Una vez completado el cambio, el propietario antiguo y el nuevo se convierten automáticamente en copropietarios conjuntos, de modo que ambos conservan el acceso al historial de ejecución y a las referencias de conexión. Encontrarás más detalles al respecto en el artículo enlazado sobre Solutions in Power Automate.
Tras la eliminación en el centro de administración de Microsoft 365, según la documentación oficial puede tardar entre 30 minutos y 6 horas en que el estado cambie a desactivado en los entornos de Power Platform correspondientes. Si no quieres asumir ese tiempo de espera, puedes comprobar y acelerar el estado manualmente mediante el diagnóstico de usuario en el centro de administración.
No, no es suficiente y más bien crea nuevos problemas. Si solo eliminas la conexión, el flujo sigue vinculado a la persona que se marchó como propietaria y funciona en el vacío sin una conexión operativa. El orden correcto es el inverso: primero transferir el propietario a una persona activa, y luego actualizar las conexiones afectadas con las credenciales de esa nueva persona.
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
Todo usuario de M365 llega automáticamente al entorno predeterminado de Power Platform, a menudo con una protección DLP mínima. Así se cierra esta brecha.
¿Power Automate o Power Apps? Así decides, con criterios oficiales de Microsoft, si tu proceso necesita un flow o una aplicación.
Cuando el propietario de un flow deja la empresa, un offboarding olvidado pone en peligro los procesos automatizados y el acceso a conexiones sensibles. Implementamos estructuras de copropiedad y un proceso de offboarding fiable para su Power Platform, antes de que la próxima salida se convierta en un problema. Así sus flows y Power Apps permanecen bajo control incluso con cambios de personal.