Cómo evitar la dependencia de una persona en Power Automate — para que los flujos no se detengan cuando quien los creó se va

«Teníamos un empleado que dominaba Power Automate y automatizó procesos en toda la empresa. Pero el mes que viene se marcha y nadie sabe qué hace cada flujo» — este tipo de consulta se ha vuelto notablemente más frecuente en los últimos tiempos. A veces llega incluso en una etapa posterior, cuando la persona ya se fue: «desde el mes pasado dejamos de recibir el correo de aviso de pedidos y no hay nadie que sepa arreglarlo».

Ya tratamos el traspaso de un sistema cuando quien lo creó ya no está en el artículo «Cuando se hereda un sistema sin código fuente ni documentación — procedimiento práctico para operarlo y mantenerlo sin detenerlo». Como los flujos de Power Automate se pueden crear sin código, esta misma situación se produce todavía con más facilidad, y además no existe la garantía de que «sigan ahí» como un ejecutable. Un flujo está fuertemente vinculado a la cuenta de quien lo creó y a sus conexiones, y la forma en que se rompe cambia en el momento en que esa cuenta se deshabilita o se elimina. En este artículo confirmamos, con la documentación oficial de Microsoft, qué le ocurre exactamente a un flujo cuando se queda sin propietario, y organizamos —en el orden en que lo abordaría una pyme— qué hacer antes de una baja de personal, qué se puede hacer después, y cómo diseñar el inventario y las cuentas de ejecución para evitar de raíz la dependencia de una sola persona.

1. Conclusión, primero

• El flujo tiene como propietario a quien lo creó, y la conexión que usa para ejecutarse (la autenticación hacia SharePoint u Outlook, por ejemplo) queda vinculada a la cuenta de esa persona. Una conexión compartida solo se puede usar dentro de ese mismo flujo y ni siquiera un copropietario puede cambiar las credenciales de una conexión creada por otra persona. ¹
• Aunque el propietario deje la empresa, el flujo sigue funcionando si quedan copropietarios. Sin embargo, las acciones que usan la conexión de esa persona empiezan a fallar, por lo que es necesario sustituir la conexión. ¹²
• Un flujo sin ningún propietario válido se convierte en un «flujo huérfano» (orphaned flow). El administrador puede localizarlo en la página del entorno del Centro de administración de Power Platform (Recursos → Flujos) y añadir un nuevo propietario desde «Compartir». También es posible procesarlo de forma masiva con PowerShell (Get-AdminFlow, Set-AdminFlowOwnerRole). ²
• Antes de la baja, el enfoque es de dos etapas: «añadir copropietarios» y «cambiar el propietario». El traspaso de propiedad (mientras la persona sigue en la empresa) solo es posible en flujos compatibles con soluciones; los flujos que no pertenecen a una solución hay que reconstruirlos añadiéndolos a una solución o mediante exportación/importación. ³⁴
• El problema de que los correos de notificación sigan enviándose a nombre de esa persona se resuelve orientando el envío hacia un buzón compartido (la acción «Enviar un correo electrónico desde un buzón compartido (V2)»), de modo que la baja no lo afecte. La propia guía de Microsoft recomienda usar un remitente compartido, en lugar de uno personal, para las notificaciones que forman parte de un proceso estándar. ⁵⁶
• Una cuenta de servicio basada en una cuenta de usuario compartida no se recomienda como buena práctica, y para los flujos de misión crítica la recomendación oficial es la propiedad mediante una entidad de servicio (service principal). Sin embargo, en una pyme la configuración y la licencia suponen un obstáculo, así que en el capítulo 5 de este artículo organizamos un criterio realista para decidir entre ambas opciones. ⁴⁷⁸
• El primer paso no es técnico, sino el inventario. Se empieza por listar, con el Centro de administración y Get-AdminFlow, qué flujos existen en la empresa, y por crear un registro mínimo de flujos (nombre, propósito, propietario, conexión, proceso afectado). ⁹

2. Cómo se produce la dependencia de una persona en los flujos

La dependencia de una sola persona en Power Automate no surge por mala fe ni por negligencia, sino por la acumulación de buenas intenciones. El recorrido típico es este:

1. Alguien que conoce bien el trabajo del día a día crea un flujo para facilitar su propia tarea. Algo pequeño, como «volcar las respuestas de Forms en Excel».
2. Como resulta útil, el resto se va sumando. Llegan peticiones como «mándenos también ese aviso a nuestra sección» o «¿no se podría guardar también el pedido?», y los flujos se multiplican y crecen.
3. Sin darse cuenta, el flujo se cuela en el núcleo del negocio. Procesos que «si se detienen, paran el trabajo» —el primer aviso de un pedido, el guardado de facturas, la circulación de una aprobación— terminan ejecutándose en un flujo de la cuenta personal de esa persona.
4. El flujo funciona de manera estable sin que nadie conozca su contenido. Como no hay motivo para tocar algo que funciona, no se crea ni traspaso ni documentación. «No se toca porque funciona» se convierte, sin más, en «nadie puede tocarlo».

Esta dinámica es la misma que cuando un desarrollador se va y queda un sistema sin código fuente ni documentación. Pero Power Automate tiene dos aspectos más problemáticos que un sistema heredado (legacy). Primero, el flujo se crea en «Mis flujos», un espacio personal, de modo que nadie salvo su creador puede ver siquiera que existe. A diferencia de un sistema cuyo ejecutable permanece en un servidor, un flujo ni siquiera aparece en un listado a menos que se haga un inventario. Segundo, la ejecución del flujo depende de la cuenta y de la conexión de quien lo creó. En el instante en que, al procesar la baja, se deshabilita o se elimina esa cuenta, el impacto se hace visible. En el capítulo siguiente confirmamos con precisión este comportamiento.

Un término antes de continuar: qué es un «flujo compatible con soluciones»

Como este término aparece repetidamente en los capítulos siguientes, conviene fijarlo aquí. Una solución es un contenedor para transportar en conjunto un flujo y sus componentes (referencias de conexión, tablas de Dataverse, aplicaciones, etc.). Para usarla hace falta un entorno con Dataverse, y a un flujo creado dentro de una solución (o añadido a ella después) se le llama flujo compatible con soluciones (solution-aware flow). ¹⁰

En el contexto de un traspaso, lo que realmente importa es la siguiente diferencia:

La pregunta de «por qué un flujo compatible con soluciones sí permite cambiar el propietario» la responde la primera fila de esta tabla. En un flujo normal, el propietario está incorporado en la propia identidad del flujo, así que no se puede sustituir después. En un flujo compatible con soluciones, ese vínculo está separado, por lo que el propietario sí se puede reemplazar. ³ En otras palabras, la medida más eficaz contra la dependencia de una persona es meter desde el principio los flujos importantes en una solución. La decisión de adoptarla se trata en el capítulo 7.

3. Qué le ocurre a un flujo cuando desaparece la cuenta

El flujo en sí no desaparece, pero se convierte en un «flujo huérfano»

Como punto de partida: aunque se elimine de Microsoft Entra ID la cuenta de la persona que se fue, los flujos que creó no se eliminan automáticamente. Los flujos y las conexiones están clasificados como elementos que «el administrador debe revisar y eliminar manualmente», así que no desaparecen por sí solos; en cambio, el historial de ejecuciones sí se elimina automáticamente al eliminar la cuenta. Hay que tener cuidado si se dependía de ese historial como evidencia. ¹¹

Aunque el flujo permanezca, si se queda sin ningún propietario válido pasa a un estado llamado flujo huérfano (orphaned flow). La documentación de soporte de Microsoft define un flujo huérfano como «un flujo sin propietario válido» y señala explícitamente que si usa una conexión vinculada a la cuenta de un usuario que se fue, el flujo puede fallar. ²

La conexión está vinculada a la cuenta de la propia persona

Este es el punto más delicado de todos. La conexión que usa cada acción de un flujo (la autenticación hacia SharePoint, Outlook, Teams, etc.) funciona con las credenciales del usuario que la creó. Las preguntas frecuentes oficiales sobre qué ocurre cuando el creador de un flujo compartido deja la empresa lo resumen así: ¹

• Si quedan propietarios válidos, como copropietarios, el flujo en sí sigue funcionando
• Sin embargo, las acciones que usan la conexión a nombre de la persona que se fue pueden fallar, así que hace falta actualizar las credenciales de la conexión (en la práctica, sustituir en la pantalla de edición del flujo la conexión de cada acción por la de otra cuenta)

Además, una conexión compartida solo se puede usar dentro de ese mismo flujo, y ni siquiera un copropietario puede cambiar las credenciales de una conexión creada por otro propietario. ¹ Es decir, «ya añadí copropietarios, así que está resuelto» solo es cierto a medias: el traspaso no se completa hasta que se hace el trabajo de sacar la conexión de la persona que se fue del flujo (sustituyéndola por la propia en cada acción y guardando).

El arrastre de la licencia: el caso que se desactiva en 14 días

Un flujo que usa conectores premium, entre otros, funciona con la licencia de su propietario. Según las preguntas frecuentes oficiales sobre licencias, un flujo premium que pierde el respaldo de la licencia —por ejemplo, porque el propietario deja la empresa— se degrada a un estado de rendimiento reducido, se notifica a todos los propietarios y, si no se actúa, se desactiva a los 14 días. ⁴ Es un comportamiento con plazo: el flujo «se nota un poco más lento» y, dos semanas después, se detiene. Los flujos que solo usan conectores estándar rara vez tienen este problema, pero conviene saber, mediante el inventario, qué flujos usan funciones premium (la frontera entre estándar y premium la organizamos en «Licencias de Power Automate y la frontera entre conectores estándar y premium»).

El problema de que el correo siga enviándose a nombre de la persona

Un aspecto que suele pasarse por alto es el «remitente» de las notificaciones. La acción «Enviar un correo electrónico (V2)» envía desde el buzón del usuario conectado, así que, mientras el flujo siga funcionando, los correos de notificación siguen saliendo a nombre personal de quien lo creó. Mientras esa persona sigue en la empresa, el problema se queda en un «¿por qué llega ese correo cada mañana de esa persona?», pero tras la baja, el propio envío falla en cuanto se deshabilita la cuenta. Y si, a la inversa, un copropietario se limita a sustituir la conexión por la suya, entonces todas las notificaciones pasan a salir a su propio nombre.

La guía de Microsoft recomienda evitar enviar a nombre personal las notificaciones que forman parte de un proceso estándar de la empresa, y usar en su lugar un remitente compartido. En Outlook, la acción «Enviar un correo electrónico desde un buzón compartido (V2)» permite enviar desde un buzón compartido (por ejemplo, noreply-flow@example.co.jp), y el historial de envíos queda también en la carpeta de elementos enviados de ese buzón compartido (el envío requiere permiso de acceso al buzón). Para las notificaciones en Teams, las acciones del tipo «Publicar como el bot de flujo» cumplen el mismo papel. Además, añadir una firma del tipo «Este correo se envía automáticamente desde Power Automate. Para consultas, contacte con XX» evita confusiones en el destinatario aunque cambie la persona responsable. ⁵⁶

4. Qué hacer antes de una baja y qué se puede hacer después

Antes de la baja: con dos semanas es suficiente

Cuando se confirma una baja o un traslado, se procede con estos seis pasos. La vista general es esta (los números corresponden a cada paso descrito a continuación):

flowchart TD
    accTitle: Pasos previos a la baja para traspasar un flujo de Power Automate
    accDescr: Diagrama de flujo que muestra los seis pasos a seguir antes de una baja o traslado: listar y clasificar los flujos, añadir copropietarios, decidir si el flujo es compatible con soluciones para cambiar el propietario directamente o reconstruirlo, sustituir las conexiones de cada acción, mover el remitente de las notificaciones a un buzón compartido y probar que todo funcione sin la cuenta de la persona que se va.
    Start["Se confirma la baja o el traslado"] --> S1["① Listar y clasificar los flujos"]
    S1 --> S2["② Añadir copropietarios"]
    S2 --> Q{"¿Es un flujo compatible con soluciones?"}
    Q -- Sí --> S3a["③ Cambiar el propietario desde la pantalla de detalles"]
    Q -- No --> S3b["③ Añadir a una solución y cambiar el propietario, o reconstruir el flujo"]
    S3a --> S4["④ Sustituir la conexión de cada acción"]
    S3b --> S4
    S4 --> S5["⑤ Mover el remitente de las notificaciones a un buzón compartido"]
    S5 --> S6["⑥ Probar que funcione aunque la cuenta de la persona esté deshabilitada"]

1. Listar y clasificar los flujos. Se abre la pantalla de Mis flujos junto con la propia persona y se clasifican en «los que se usan en el trabajo», «los de productividad personal» y «restos de pruebas». Es eficiente aprovechar este paso para crear ya la primera versión del registro de flujos del capítulo 6.
2. Añadir copropietarios. Se añade como propietarios del flujo a la persona que asume el puesto y al responsable de sistemas (o, si no lo hay, a alguien con permisos de administrador). Un copropietario puede consultar el historial de ejecuciones, editar el flujo, detenerlo, eliminarlo e incluso añadir propietarios. ¹ Cabe señalar que añadir copropietarios es solo una medida mínima de emergencia; la recomendación oficial es que el uso compartido cotidiano se limite, en la medida de lo posible, a solo ejecución (run-only). ⁷
3. Cambiar el propietario. Si es un flujo compatible con soluciones, se puede cambiar el propietario desde la pantalla de detalles del flujo hacia la persona que asume el puesto (o una cuenta de servicio). Tras el cambio, el propietario original y el nuevo pasan a ser copropietarios, y los flujos programados o automáticos empiezan a ejecutarse con la licencia del nuevo propietario (el cambio tarda hasta 7 días en reflejarse; abrir el flujo y guardarlo lo aplica de inmediato). ³ Como se vio en el capítulo 2, un flujo sin solución no permite cambiar el propietario, así que, si el entorno cuenta con Dataverse, se añade primero a una solución y luego se cambia; si no, se reconstruye bajo el nuevo propietario mediante exportación/importación o «Guardar como». ³⁴
4. Sustituir las conexiones. Como se vio en el capítulo anterior, si se salta este paso el traspaso no queda completo. En la pantalla de edición del flujo se cambia la conexión de cada acción por la conexión de la nueva cuenta y se guarda. También al retirar a la persona que se fue de la lista de propietarios hace falta actualizar las conexiones que usaban sus credenciales. ¹
5. Trasladar el remitente de las notificaciones. Los flujos que usan «Enviar un correo electrónico (V2)» a nombre personal se cambian, como se explicó en el capítulo 3, al envío desde un buzón compartido. Si no se corrige este punto, tras el traspaso todas las notificaciones pasarán a salir a nombre de la persona que asume el puesto. ⁵⁶
6. Probar. Si es posible, se ejecuta un ciclo completo con la cuenta de la persona deshabilitada (o durante un período en que no la use, como unas vacaciones), para confirmar que funciona en las mismas condiciones que tras la baja.

Después de la baja: lo que puede hacer un administrador

Incluso cuando la persona ya se ha ido y no queda propietario, hay margen de actuación.

• Localizar los flujos huérfanos en el Centro de administración. La navegación en pantalla es la siguiente. ²

  1. Iniciar sesión en el Centro de administración de Power Platform
  2. En el menú izquierdo, elegir el entorno correspondiente desde «Entornos» (Environments)
  3. En la página de detalles del entorno, abrir «Recursos» (Resources) → «Flujos» (Flows)
  4. Observar la columna «Propietario» (Owners) del listado. Los flujos con esta columna vacía son los flujos huérfanos

  Dicho de otro modo, en esta pantalla el único objetivo es «buscar las filas con la columna de propietario vacía». En un entorno con muchos flujos, es más fiable ordenar por esta columna o filtrarlos de forma mecánica con PowerShell, como se explica más adelante.

• Añadir un nuevo propietario desde «Compartir». Se elige el flujo correspondiente en el listado y, desde «Compartir» (Share), se añade la cuenta del nuevo propietario y se guarda. ² Cabe señalar que, si el administrador quiere modificar el contenido del flujo, primero debe añadirse a sí mismo como propietario o copropietario. ³
• Si hay muchos, procesarlos en bloque con PowerShell. Con el módulo de administración (Microsoft.PowerApps.Administration.PowerShell), Get-AdminFlow -CreatedBy <ID de objeto de la persona que se fue> enumera los flujos que creó, y Set-AdminFlowOwnerRole -RoleName CanEdit permite otorgar la copropiedad. Los permisos actuales se comprueban con Get-AdminFlowOwnerRole. ²
• Reconstruir las conexiones. Tras traspasar la propiedad, se sustituye la conexión a nombre de la persona que se fue por la conexión de la nueva cuenta. Si su cuenta ya se ha eliminado, la conexión original no se puede recuperar, así que hay que crear una conexión nueva y volver a asignarla en cada acción. ¹

Como apunte adicional, en el caso concreto de los flujos de aprobación existe otro tipo de atasco: que una solicitud pendiente quede asignada a la persona que se fue. La reasignación del lado del aprobador y el diseño de escalamiento se trataron en los capítulos 5 y 6 de «Cómo crear un flujo de aprobación en Power Automate», así que remitimos a ese artículo.

5. Diseño de la cuenta de ejecución: personal, cuenta de servicio o entidad de servicio

Para no repetir este tipo de sobresaltos en cada traspaso, la medida de fondo es decidir desde el principio «a nombre de quién se ejecuta el flujo de negocio».

Antes de nada, conviene explicar solo la «licencia Process», que aparece en la tabla comparativa. Las licencias de Power Automate se dividen a grandes rasgos en dos tipos: la licencia de usuario se asigna a una «persona», mientras que la licencia Process es una licencia de capacidad que se asigna al propio «flujo» (o a la máquina de ejecución). ¹² Al asignarla a un flujo en la nube, se pueden usar conectores premium y personalizados sin importar qué licencia tenga el usuario que posee o ejecuta ese flujo (para asignarla, es condición que el flujo esté dentro de una solución). ¹²

Una entidad de servicio (service principal) no es una persona, así que no puede tener una licencia de usuario. De ahí que la fórmula sea: «si un flujo con funciones premium pasa a ser propiedad de una entidad de servicio, hay que asignarle una licencia Process al propio flujo». Por el contrario, si el flujo solo usa conectores estándar, no hace falta. ⁸ La propia frontera entre estándar y premium la organizamos en «Licencias de Power Automate y la frontera entre conectores estándar y premium».

Con esto claro, comparamos las opciones.

Como criterio práctico para decidir entre ellas:

• Las herramientas de productividad personal pueden seguir con una cuenta personal sin problema. Si se intenta gestionarlo todo con rigor, la propia automatización del día a día se resiente.
• En un flujo de negocio del que depende un departamento, como mínimo hay que orientar el remitente de las notificaciones a un buzón compartido ⁵ y tener dos o más copropietarios. Si se crea una cuenta de servicio para la ejecución, hay que limitar los permisos al mínimo necesario y restringir a unas pocas personas el acceso a las credenciales. La propia Microsoft indica que, antes que usar una cuenta de servicio, es mejor usar una entidad de servicio ⁴, pero en una operación de tamaño pequeño o mediano centrada en conectores estándar, «una cuenta dedicada más una gestión estricta de la contraseña» suele ser la solución realista en muchos casos.
• Un flujo que forma parte del núcleo de toda la empresa (directamente ligado a pedidos, facturación o pagos) merece considerar la propiedad mediante una entidad de servicio. Como el propietario deja de ser una persona, no sufre el impacto de una baja, y también se evita el accidente de que el flujo se detenga por la pérdida de licencia del propietario. ⁸ Sin embargo, una entidad de servicio no puede ser copropietaria (solo se usa como propietaria), y las funciones premium requieren una licencia Process, entre otras restricciones; llegados a este punto, conviene diseñarlo con el departamento de TI o con un especialista externo. ⁸

Cabe señalar que, incluso al crear una cuenta de servicio, conviene evitar hacer toda la creación de flujos y los pequeños ajustes a su nombre; si quien construye lo hace desde su propia cuenta y solo la propiedad y la ejecución se orientan a la cuenta de servicio, se mantiene la trazabilidad de «quién cambió qué y cuándo».

6. Inventario y documentación: primero, saber «qué hay»

El punto de partida frente a la dependencia de una sola persona es que la organización, como tal, sepa qué flujos existen en la empresa. Igual que al heredar un sistema convertido en caja negra lo primero es inventariar los ejecutables y las tareas, en el caso de los flujos también existe una rutina establecida de inventario.

Obtener el listado de flujos

• Desde el Centro de administración: al abrir «Recursos» → «Flujos» en la página del entorno del Centro de administración de Power Platform, se obtiene un listado de los flujos del entorno junto con su propietario. Aquí también se localizan los flujos huérfanos. ²
• Desde PowerShell: el cmdlet de administración Get-AdminFlow devuelve, si lo ejecuta un administrador de entorno, todos los entornos bajo su administración, y si lo ejecuta un administrador global, todos los flujos del inquilino (tenant). Con Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' se obtiene directamente la semilla de un registro en CSV, y con Get-AdminFlowWithHttpAction también se puede filtrar solo los flujos que usan una acción HTTP (los que probablemente se integran con sistemas externos). ⁹ Si no está familiarizado con PowerShell, puede consultar también «Fundamentos de los comandos de PowerShell — las operaciones básicas y un uso seguro».

Un registro mínimo de flujos

El truco para que un registro se mantenga en el tiempo es no complicarlo. Basta con una lista de SharePoint o un Excel, una fila por flujo, con solo las siguientes columnas.

El punto clave es la columna de «a nombre de quién está la conexión». El propietario se puede ver en la pantalla de administración, pero el nombre de la conexión solo se conoce si se abre el flujo, así que es la información que más vale la pena anotar en el registro.

La convención de nomenclatura y el campo «Descripción»

Las directrices de codificación de Microsoft recomiendan poner nombres descriptivos y coherentes a los componentes de un flujo, documentar y compartir la convención de nomenclatura, y añadir a las acciones notas equivalentes a los comentarios de un código. ¹³ En la práctica, con solo uniformar el nombre del flujo como «[Departamento] Nombre del proceso - Contenido del tratamiento» (por ejemplo, «[Ventas] Pedido por fax - Guardar PDF y notificar al responsable»), la legibilidad del listado cambia notablemente. Además, la pantalla de detalles del flujo tiene un campo de descripción (Description), y hasta se le puede pedir a Copilot que genere un borrador ¹⁴, así que si el propio flujo lleva el mismo contenido que la columna «Propósito» del registro, sirve de seguro para cuando el registro quede desactualizado.

Al crear el registro aparece el siguiente problema: quién se da cuenta cuando el flujo se detiene por un error. El diseño de las notificaciones de fallo y los reintentos se trata en detalle en «Manejo de errores y diseño de reintentos en Power Automate».

7. Entornos y soluciones: un paso más allá de «todo en el entorno predeterminado»

Power Platform tiene un compartimento llamado «entorno», y todos los flujos creados sin especificar nada van al entorno predeterminado (default environment). Todos los usuarios del inquilino tienen acceso a él, y cualquier empleado con licencia de Microsoft 365 puede crear ahí aplicaciones o flujos. Como espacio de juego para mejorar la productividad individual, está bien así, pero la propia guía de Microsoft señala que en el entorno predeterminado tienden a acumularse recursos sin propietario a causa de las bajas de quienes los crearon, y que los flujos que se comparten ampliamente o que adquieren importancia para el negocio deberían trasladarse a un entorno dedicado. ¹⁵

Una pyme no necesita, desde el principio, implantar una separación de entornos en toda regla (desarrollo, pruebas, producción). Aun así, hay dos puntos que merece la pena tener presentes desde que la escala todavía es pequeña.

• Meter en una solución los flujos que forman parte del núcleo del negocio. Una solución es un contenedor para transportar en conjunto un flujo y sus componentes; un flujo metido en ella (un flujo compatible con soluciones) permite cambiar el propietario sobre la marcha, mantener la conexión en la forma fácil de sustituir de una «referencia de conexión», y usar el historial de versiones. ³¹⁰ Como se vio en el capítulo 4, la facilidad de traspaso ante una baja no tiene comparación. Para usarla hace falta un entorno con Dataverse. ¹⁰
• Revisar al menos una vez la política de DLP. La política de prevención de pérdida de datos (DLP), que clasifica los conectores en profesionales y no profesionales y restringe sus combinaciones, funciona como red de seguridad frente al accidente de que un flujo no controlado filtre datos internos hacia un servicio externo. ¹⁶ El planteamiento general de gobernanza se aborda en el capítulo 9 de «Automatizar procesos con Power Automate».

Más allá de esto están temas como la separación de entornos, el ALM (la canalización de desarrollo → pruebas → producción) o el control de toda la empresa mediante el CoE Starter Kit, pero basta con considerarlos cuando los flujos alcancen la escala de varias decenas. Primero el registro y la conversión a solución; después, el entorno.

8. Tabla de criterios: de quién es ese flujo

Por último, dónde trazar la línea sobre el nivel de gestión de cada flujo. Gestionar con rigor todos los flujos no es realista, así que se dividen en tres niveles según «a quién perjudica que se detenga».

La forma de abordar un flujo que ha caído en el último nivel de la tabla es la misma que la del traspaso de un sistema sin código fuente ni documentación mencionado al principio. En lugar de reconstruirlo de inmediato, se empieza por observar el desencadenador, la conexión y el destino de salida, y por volcar en el registro «qué hace». Por suerte, a diferencia de un EXE sin código fuente, un flujo permite ver todo su contenido. Basta con llegar a ser copropietario para que descifrar su definición no resulte, en sí, difícil.

También cabe la pregunta de si, para empezar, este proceso debería seguir viviendo en Power Automate. Un flujo complejo, que tiende a convertirse en caldo de cultivo de la dependencia de una persona, a veces resulta más fácil de traspasar si se orienta hacia un script de PowerShell, el Programador de tareas o una función del propio sistema de negocio, porque entonces se puede llevar a un control con Git y a una revisión de código. Este criterio de decisión se organiza en «Cuándo usar Power Automate y cuándo PowerShell o el Programador de tareas».

9. Resumen

• El flujo está vinculado a la cuenta y a la conexión de quien lo creó. Aunque la cuenta desaparezca al producirse una baja, el flujo en sí permanece, pero el historial de ejecuciones se elimina automáticamente, las acciones que usan la conexión a nombre de la persona que se fue fallan, y un flujo premium se desactiva tras un plazo de gracia de 14 días. ¹¹²⁴
• Antes de la baja, con dos semanas basta para completar el traspaso en este orden: añadir copropietarios → cambiar el propietario (si es compatible con soluciones) → sustituir las conexiones → cambiar el remitente a un buzón compartido. ³¹
• Incluso tras la baja, se pueden localizar los flujos huérfanos y reasignar el propietario desde «Recursos → Flujos» del Centro de administración o con PowerShell (Get-AdminFlow/Set-AdminFlowOwnerRole). Aun así, no se puede evitar reconstruir las conexiones. ²
• La medida de fondo es el inventario mediante un registro de flujos, la convención de nomenclatura y el campo de descripción, compartir el remitente de las notificaciones, y un diseño que separe de una persona la ejecución de los flujos importantes (cuenta de servicio con cautela, entidad de servicio para el núcleo del negocio). ¹³⁶⁷
• Decidir, para cada flujo, si es «una herramienta personal», «un activo del equipo» o «infraestructura de la empresa», y ajustar a eso el peso de la gestión. Creemos que esta es la línea realista para evitar la dependencia de una sola persona sin frenar la automatización del día a día.

Aunque quien lo creó no tenga previsto ningún traslado ni baja, recomendamos hacer al menos una vez, a modo de «simulacro», los pasos hasta el capítulo 4 de este artículo. Si tiene dudas sobre el inventario o el diseño del traspaso de sus flujos, o sobre si un proceso debería vivir o no en Power Automate, no dude en consultarnos.

Artículos relacionados

• Automatizar procesos con Power Automate — cuándo usar flujos en la nube o de escritorio y cómo diseñar el manejo de errores
• Cómo crear un flujo de aprobación en Power Automate — digitalizar las solicitudes y aprobaciones en papel y correo
• Cuando se hereda un sistema sin código fuente ni documentación — procedimiento práctico para operarlo y mantenerlo sin detenerlo
• Manejo de errores y diseño de reintentos en Power Automate
• Licencias de Power Automate y la frontera entre conectores estándar y premium

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa desde la investigación de traspaso de automatizaciones y sistemas de negocio que nadie puede tocar tras la baja o el traslado de su responsable, hasta la revisión del diseño operativo de Power Automate y la sistematización de procesos que ya no caben en un flujo.

• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones para Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué ocurre con un flujo de Power Automate cuando la persona que lo creó deja la empresa?

El flujo en sí no desaparece automáticamente al eliminar la cuenta de la persona que se fue, y sigue funcionando si quedan copropietarios. Sin embargo, las conexiones dentro del flujo (la autenticación hacia SharePoint u Outlook, por ejemplo) están vinculadas a la cuenta de quien las creó, de modo que las acciones que usan la conexión de esa persona empiezan a fallar en cuanto su cuenta se deshabilita o se elimina. Además, un flujo sin ningún propietario válido se convierte en un «flujo huérfano»; si el flujo usa funciones premium, su rendimiento se degrada cuando el propietario pierde la licencia y, si no se corrige, el flujo se deshabilita a los 14 días. Por eso es fundamental añadir copropietarios y sustituir las conexiones antes de que la persona se marche.

¿Puede un administrador hacerse cargo de un flujo creado por alguien que ya dejó la empresa?

Sí. En el Centro de administración de Power Platform, al elegir el entorno y abrir «Recursos» → «Flujos», se pueden ver los flujos huérfanos sin propietario y añadir un nuevo propietario desde «Compartir». Si hay muchos flujos, también se puede obtener el listado con el cmdlet de administración Get-AdminFlow de PowerShell y añadir copropietarios de forma masiva con Set-AdminFlowOwnerRole. Aun así, aunque se traspase la propiedad, las conexiones a nombre de la persona que se fue no funcionarán tal cual, por lo que hace falta un trabajo aparte: sustituir la conexión de cada acción del flujo por una conexión de la nueva cuenta.

¿Basta con añadir copropietarios como medida frente a una baja de personal?

No es suficiente. Un copropietario puede editar el flujo, detenerlo o añadir propietarios, pero no puede cambiar las credenciales de una conexión creada por otra persona, y una conexión compartida solo se puede usar dentro de ese mismo flujo. Las acciones que dependen de la conexión de quien se fue solo seguirán funcionando cuando un copropietario las sustituya por su propia conexión. Además persiste el problema de que los correos de notificación sigan enviándose a nombre de la persona que se fue, así que conviene combinarlo con un diseño más amplio: enviar las notificaciones desde un buzón compartido y, en los flujos que forman parte del núcleo del negocio, orientar la propiedad hacia una cuenta de ejecución dedicada o una entidad de servicio (service principal).

¿Conviene crear una cuenta de servicio compartida para ejecutar los flujos?

Es una opción, pero Microsoft no recomienda como buena práctica una cuenta de servicio basada en una cuenta de usuario compartida entre varias personas: al compartirse la contraseña entre varios, resulta difícil rastrear quién la cambió, y la propia gestión de la contraseña se convierte en un riesgo. Si se opta por esta vía, hay que limitar los permisos al mínimo necesario y restringir quién puede acceder a las credenciales. Para los flujos de misión crítica, Microsoft recomienda oficialmente la propiedad mediante una entidad de servicio (service principal), que no depende de la cuenta de una persona, aunque su configuración requiere conocimientos de TI y, si el flujo usa funciones premium, hace falta una licencia Process.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.