Checklist de offboarding de Power Platform

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.

Por qué el offboarding en la Power Platform se olvida a menudo

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.

La checklist antes del último día laboral

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.

• Exportar la lista de flujos: Pide a la persona que inicie sesión en Power Automate y liste en "Mis flujos" todos sus propios flujos, incluidos los que aparecen en "Compartidos conmigo".
• Comprobar la pertenencia a una solución: Para cada flujo: solo un flujo compatible con soluciones (solution-aware) puede transferirse más adelante de forma limpia a una nueva persona. Para los flujos que no son compatibles con soluciones, la documentación indica que la única opción es el rodeo mediante exportar, importar o enviar una copia, porque el propietario forma parte de la identidad del flujo.
• Añadir un copropietario: Añade directamente un copropietario del equipo para cada flujo crítico, mientras la persona original siga disponible y pueda responder dudas.
• Revisar las Power Apps: Repasa igualmente sus propias apps y comparte el acceso de copropietario para cada app que otras personas usen en producción.
• Documentar las conexiones: ¿Qué conexiones (SharePoint, Outlook, Dataverse, APIs externas) están vinculadas a los flujos de esa persona? Las conexiones ligadas a una cuenta personal dejarán de funcionar de forma fiable una vez desactivada la cuenta.
• Redirigir los procesos de aprobación y de uso compartido: Si la persona actúa como aprobadora en un flujo de aprobación, ese rol debe reasignarse a otra persona antes de su salida.

La checklist después del último día laboral

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.

• Encontrar flujos huérfanos en el centro de administración: Abre el Power Platform Admin Center, selecciona el entorno afectado, luego Recursos > Flujos, y busca específicamente flujos sin entrada en la columna Propietario. Ese es exactamente el camino que describe el artículo de soporte sobre Administrar flujos huérfanos.
• Asignar nuevos copropietarios: Para cada flujo encontrado en el centro de administración, selecciona Compartir, introduce un nuevo nombre de propietario y guarda. Para muchos de los flujos afectados, esto también se puede hacer a gran escala mediante los cmdlets de PowerShell `Get-AdminFlow` y `Set-AdminFlowOwnerRole`, en lugar de hacer clic en cada flujo por separado.
• Buscar las Power Apps de la misma persona: En Recursos > Power Apps puedes filtrar por el nombre de la persona que se marchó. Para cada app encontrada, basta un clic en Compartir para asignarte a ti mismo, como administrador, los derechos de copropietario.
• Comprobar el grupo de seguridad y la licencia: En cuanto la persona se elimina del centro de administración de Microsoft 365, Power Platform pone automáticamente su estado en desactivado, lo que según la documentación sobre Eliminar usuarios de un entorno puede tardar entre 30 minutos y 6 horas. No esperes ese plazo sin comprobarlo; controla activamente si el estado realmente ha cambiado.
• Vigilar las conexiones con errores: Revisa en los flujos afectados el historial de ejecución en busca de ejecuciones fallidas debidas a una conexión no válida, y actualiza las credenciales a una cuenta que siga existiendo.

Qué ocurre si nadie actúa

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.

Prevenir: copropietarios desde el principio

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.

Preguntas frecuentes

¿Cuál es la diferencia entre un flujo huérfano y un flujo sin copropietario?

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.

¿Puedo, como administrador, quedarme sin más con el flujo de otra persona, incluso sin que nadie me lo haya compartido?

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.

¿Qué ocurre con una solución cuando su creador deja la empresa?

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.

¿Cuánto tarda la Power Platform en marcar como desactivado a un usuario eliminado?

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.

¿Basta con eliminar las conexiones de una persona en lugar de cambiar el propietario del flujo?

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.