Compartir a través de


Administrar flujos compartidos con usuarios fuera de un entorno

A partir de junio de 2025, cualquier flujo compartido con un usuario que no sea miembro del ambiente se vuelve inaccesible para ese usuario. Este cambio importante en Power Automate requiere que los usuarios sean miembros de un ambiente para acceder a los flujos en ese ambiente. Este cambio mejora la seguridad al aplicar los límites del ambiente. Sin embargo, afecta a las organizaciones que tienen flujos compartidos en diferentes ambientes, por ejemplo, el propietario de un flujo que agrega a alguien fuera del ambiente como copropietario o usuario de solo ejecución.

Para cumplir con la nueva directiva, los administradores de Power Platform deben identificar los flujos compartidos con usuarios fuera de su ambiente y ajustar la configuración de uso compartido de esos flujos. Este artículo proporciona un enfoque estructurado para hacerlo.

Este artículo le ayuda a hacer lo siguiente:

  • Identifique los flujos compartidos con usuarios externos (usuarios que no están en el ambiente del flujo).
  • Ajuste el uso compartido y el acceso a esos flujos para garantizar la continuidad (por ejemplo, agregue los usuarios adecuados a los ambientes y use acceso solo de ejecución).

Este artículo permite a los administradores de Power Platform abordar de forma preventiva los problemas de uso compartido antes de la aplicación de junio de 2025. También puede ayudar a establecer gobernanza para gestionar el uso compartido de flujos de forma segura en el futuro. Para ilustrar los puntos clave, este artículo incluye ejemplos reales e instrucciones paso a paso.

Aprenda los procedimientos recomendados para administrar flujos compartidos en Compartir un flujo de nube.

Identificar los flujos compartidos con usuarios ajenos a su entorno

El primer paso es hacer un inventario de todos los flujos de nube y sus usuarios compartidos en cada entorno, y luego identificar qué flujos tienen flujos compartidos con usuarios externos, es decir, usuarios que no son miembros de ese entorno. Los flujos de Power Automate se pueden crear de dos maneras: como flujos normales (que no son de solución) o como flujos compatibles con la solución (parte de una solución de Dataverse). Ambos residen en un ambiente y ambos necesitan revisión. En las secciones siguientes se describen los métodos para identificar flujos compartidos externamente.

Centro de administración de Power Platform método GUI

Los administradores del entorno pueden utilizar el centro de administración de Power Platform para realizar una auditoría visual.

  1. En Centro de administración de Power Platform, seleccione Administrar>Entornos > (su entorno) >Recursos>Flujos.

    A enumera todos los flujos en el entorno, junto con una columna Propietarios muestra.

  2. Para cada flujo, inspeccione a los propietarios. Si un flujo tiene varios propietarios (creador y copropietarios), se comparte. Compare esos propietarios con los miembros conocidos del entorno. Por ejemplo, compare el grupo de seguridad o la lista de usuarios de ese ambiente.

  3. Indique los flujos donde hay un propietario o copropietario que no es un miembro del ambiente esperado. Por ejemplo, si el ambiente del departamento A solo debería contener usuarios del departamento A, pero ve a un copropietario del departamento B, ese flujo se comparte con un externo. Es posible que deba seleccionar el nombre de un propietario para ver los detalles o hacer una referencia cruzada con el directorio de usuario de su ambiente.

Ventajas del método del centro de administración de Power Platform-método GUI

El Centro de administración de Power Platform proporciona una interfaz fácil de usar y permite filtrar y ordenar los flujos por nombre o propietario. Puede detectar rápidamente discrepancias obvias si sabe qué equipos y usuarios pertenecen al ambiente.

Desventajas del método del centro de administración de Power Platform - método GUI

Este método es manual y no se escala bien para muchos flujos. Debe verificar individualmente a los propietarios, lo que puede llevar mucho tiempo en entornos grandes. Puede ser difícil verificar la pertenencia al ambiente directamente desde la interfaz de usuario.

PowerShell script—método automatizado

Para una auditoría sistemática y repetible, Power Automate ofrece cmdlets administrativos PowerShell para enumerar los flujos y sus propietarios. Este enfoque es eficaz para el análisis masivo en ambientes grandes o inquilinos completos. Puede escribir un script para el proceso para generar todos los flujos y resaltar los recursos compartidos externos.

Por ejemplo, este script utiliza Get-AdminFlow para recuperar todos los flujos y luego Get-AdminFlowOwnerRole para cada flujo enumerar sus propietarios y sus roles. El resultado muestra cada nombre de flujo y una viñeta de Owner: [User], Role: [Owner/Co-owner]. Puede redirigir esta salida a un archivo o procesarla más.

A continuación, determine los recursos compartidos externos: Compare el nombre principal de usuario (UPN) de cada propietario con el conjunto de usuarios que son miembros del entorno. Un recurso compartido externo lo indica cualquier propietario cuyo UPN no esté en la lista de usuarios o en el grupo de seguridad del entorno. En la práctica, podría:

  • Exporte la lista de propietarios de flujos del script anterior y la lista de usuarios del entorno, luego use Excel o un script para encontrar diferencias, o
  • Mejore el script PowerShell para realizar comprobaciones cruzadas con los usuarios del entorno de Get-AdminEnvironmentUser.

Ventajas del script PowerShell: método automatizado

Este método está automatizado y es completo. Puede enumerar cientos o miles de flujos rápidamente y se puede programar para la generación de informes. Puede ejecutarlo según una programación, por ejemplo, mensual, para detectar nuevos recursos compartidos externos.

Contras del script PowerShell: método automatizado

Requiere estar familiarizado con PowerShell y privilegios de administrador. Además, la salida sin procesar muestra UPN e identificadores de objeto. Es necesario interpretar cuáles están fuera del entorno y requieren cierto análisis. Sin embargo, esto es sencillo si conoce el dominio de usuario de su entorno o tiene una lista de miembros del entorno.

Kit de herramientas del Centro de excelencia (CoE): método de panel

Si su organización utiliza el Kit de inicio del Centro de excelencia de Power Platform, este proporciona paneles e informes de Power BI que incluyen el uso compartido de métricas. El inventario de flujos del CoE puede resaltar los flujos que tienen propietarios invitados o propietarios fuera del grupo de seguridad normal del entorno. Por ejemplo, el panel del CoE puede tener un informe de Flujos con varios propietarios o Flujos compartidos con usuarios invitados. Puede aprovechar esta información para encontrar flujos con uso compartido anormal.

Ventajas del kit de herramientas del Centro de excelencia (CoE): método de panel

Informes visuales centralizados que ya podrían estar agregando datos del entorno. No hay scripts adicionales si CoE está en su lugar. Puede marcar automáticamente los patrones no conformes.

Contras del kit de herramientas del Centro de excelencia (CoE): método de panel

Requiere que el kit de inicio del CoE se implemente y se mantenga actualizado. Es posible que los datos no sean en tiempo real (normalmente se actualizan según una programación). Además, la configuración de filtros personalizados, como la identificación de usuarios externos del dominio, puede requerir ajustes en los componentes del CoE.

Comparación de métodos de identificación

método Herramienta/Enfoque Ventajas Desventajas
Centro de administración (GUI) Interfaz web del centro de administración de Power Platform: compruebe los flujos y los propietarios visualmente. Interfaz sencilla y fácil de usar. Información inmediata para pequeñas cantidades de flujos. Verificación manual, no escalable para ambientes grandes. No hay referencia cruzada integrada del propietario contra la pertenencia al ambiente.
Script de PowerShell Cmdlets de PowerShell del administrador (Get-AdminFlow, Get-AdminFlowOwnerRole). Salida masiva automatizada de flujos y propietarios. Se puede programar y exportar los resultados a CSV u otros formatos. Alta precisión si se conoce la lista de usuarios del ambiente. Requiere conocimiento de PowerShell. Debe identificar por separado qué propietarios son externos. Necesita script o post-procesamiento.
Kit de herramientas del CoE (panel) Paneles y flujos de CoE de Power BI Ya está disponible si CoE está instalado. Puede resaltar el uso compartido inusual, como propietarios externos o invitados, en un informe centralizado. Necesita despliegue y mantenimiento de CoE. Hay un retraso en la actualización de datos (no en tiempo real). Es posible que necesite personalización para identificar usuarios externos específicos.

Con uno o una combinación de los métodos de la tabla anterior, compile una lista de flujos que tengan usuarios externos compartidos. Estos son los flujos afectados que necesitan atención antes del cambio de política. En muchas organizaciones, esto podría ser un subconjunto manejable de flujos, por ejemplo, solo unos pocos flujos entre departamentos o flujos compartidos con la cuenta de invitado de un socio. En otros, especialmente en los clientes con prácticas de uso compartido abiertas, podría haber un número importante de flujos que gestionar, por lo que cuanto antes los identifique, mejor.

Ajustar el uso compartido y el acceso para los flujos afectados

Una vez que identifique los flujos que se comparten con usuarios fuera de su ambiente, el siguiente paso es corregir la configuración de uso compartido de cada flujo. El objetivo es garantizar que todos los usuarios que necesiten acceso a un flujo se agreguen correctamente al ambiente (o que el acceso del flujo se modifique de otro modo). Haga esto para que cuando entre en vigor la nueva implementación, nadie pierda la funcionalidad. Las siguientes secciones describen cómo abordar los ajustes.

Evalúe la necesidad de cada compartición externa

Para cada flujo marcado, explique con el propietario del flujo o el equipo empresarial pertinente por qué se ha compartido externamente. Este contexto es importante para decidir la solución. En la lista siguiente se describen escenarios y acciones comunes.

  • Escenario 1: El usuario se agregó como copropietario solo para ejecutar el flujo o ver los resultados: En muchos casos, los propietarios agregaron a un usuario externo como propietario cuando lo único que necesitaban era desencadenar o usar el flujo (no editarlo). Por ejemplo, el propietario puede agregar a un agente del departamento de soporte técnico como copropietario de un flujo para poder desencadenarlo manualmente. En tales casos, es probable que el usuario no necesite todos los derechos de propietario.
  • Acción: Eliminarlos de la lista Propietarios y, en su lugar, compartir el flujo con ellos como usuarios de solo ejecución (si corresponde), después de asegurarse de que tienen acceso al entorno. Esto proporciona la capacidad necesaria para ejecutar el flujo sin convertirlos en propietarios. Obtenga más información en la sección Agregar usuarios necesarios al ambiente de este artículo.
  • Escenario 2: El usuario colabora realmente en la creación o el mantenimiento del flujo: por ejemplo, dos departamentos desarrollan conjuntamente un flujo, por lo que un usuario del departamento B se convierte en copropietario en el ambiente del departamento A.
  • Acción: Incorpore a ese usuario al ambiente como propietario correctamente con el rol adecuado, o considere la posibilidad de trasladar el flujo a un ambiente neutral si varias unidades organizativas deben ser copropietarias de él. A corto plazo, agregar el usuario a la lista de usuarios permitidos del ambiente y asignarle un rol apropiado (Creador de ambiente si necesita derechos de edición) resuelve los problemas de acceso.
  • Escenario 3: El recurso compartido ya no es necesario: a veces, los usuarios se agregaron temporalmente o abandonaron el proyecto.
  • Acción: elimine al usuario externo del recurso compartido del flujo. Esta es la solución más simple cuando corresponde. Si nadie fuera del entorno necesita el flujo, deje de compartirlo con ellos. A continuación, el flujo es compatible y solo quedan los propietarios internos.
  • Escenario 4: Recursos compartidos entre inquilinos o usuarios invitados: por ejemplo, un flujo se compartió con una cuenta de invitado (tenant externo). Esto se bloquea después de la aplicación.
  • Acción: determina si es absolutamente necesario que el huésped tenga acceso. En caso afirmativo, una opción es agregar oficialmente ese invitado como invitado de Azure AD en su arrendatario y en el grupo de seguridad del ambiente. Esto los convierte en un miembro del ambiente. Esto no suele pasar. Alternativamente, trabaje para transferir la propiedad a un usuario interno que pueda actuar en nombre del invitado, o use un mecanismo diferente, como exponer el flujo a través de un desencadenador HTTP seguro en lugar de compartir directamente. Se recomienda quitar los recursos compartidos directos de invitado porque, aunque se agreguen como miembros del ambiente, pueden surgir problemas entre inquilinos.

Añadir los usuarios necesarios al entorno

Para cada usuario que deba seguir teniendo acceso al flujo, asegúrate de que es miembro del entorno en adelante. Por lo general, esto significa:

  • Si el ambiente usa un grupo de seguridad: agregue la cuenta del usuario a ese grupo de seguridad de Azure AD. Esto les otorga el rol de usuario básico predeterminado en el ambiente, a menos que se configure lo contrario. El rol de usuario básico suele ser suficiente para alguien que solo necesita ejecutar flujos y no crear ni editar. Después de agregar, verifique que el usuario ahora aparece en la lista de usuarios del ambiente en el Centro de administración de Power Platform.

  • Si es el ambiente predeterminado del cliente, que está abierto a todos los usuarios: la mayoría de los usuarios con licencia ya están en él. Asegúrese de que el usuario tiene una licencia de Power Automate. La aplicación afecta principalmente a ambientes no predeterminados con pertenencia restringida.

  • Creador de entorno en comparación con Usuario básico: no otorgue el rol de creador de entorno a menos que la persona realmente necesite crear y editar flujos en ese entorno. En nuestras correcciones, preferimos dar solo el rol Usuario básico o un rol mínimo personalizado, que permite ejecutar flujos compartidos. Para el acceso de solo ejecución, el Usuario básico es suficiente: no es necesario que el usuario sea un creador. La limitación de las funciones de creador es una práctica recomendada de gobernanza, que se analiza con más detalle en la siguiente sección.

Ajustar la configuración de uso compartido del flujo

Ahora que el usuario es miembro del ambiente, ajuste la forma en que se comparte el flujo con él.

  • Si el usuario solo necesita ejecutar el flujo: utilice la opción de Compartir solo para ejecución. En Power Automate, abra la configuración de uso compartido del flujo. Quite al usuario de la lista Propietarios y, en la sección Usuarios de solo ejecución, agregue su nombre. En el caso de los flujos activados manualmente, como los flujos de botón y los flujos instantáneos, o los flujos activados con vínculos que se pueden compartir, se garantiza que la persona pueda activar el flujo sin ser propietario. No pueden editar ni mostrar los componentes internos del flujo y solo pueden ejecutarlo. El resultado es que el usuario permanece fuera de la lista de propietarios, por lo que no hay conflicto en el ambiente, pero puede usar la funcionalidad del flujo según lo previsto.

    Ejemplo: Bob en Marketing fue copropietario del flujo de Procesador de clientes potenciales de ventas solo para iniciarlo periódicamente. Eliminamos a Bob como copropietario y agregamos a Bob como usuario de solo ejecución. Bob también se agrega al ambiente de ventas como usuario básico. Ahora Bob puede seleccionar el botón del flujo o recibir su vínculo para ejecutarlo, pero ya no es un propietario externo, es un usuario básico autorizado de ese ambiente.

  • Si el usuario necesita permisos de propietario completos (coautoría): después de agregarlo al ambiente, asegúrese de que permanezca en la lista de propietarios en el flujo. Técnicamente, puede eliminarlos y volver a agregarlos para actualizar los permisos. Pero una vez que están en el ambiente, la acción es legítima. También puede considerar la posibilidad de trasladar el flujo a una solución si dos propietarios de diferentes áreas lo mantienen a largo plazo. Los flujos de solución son más fáciles de transportar a un ambiente dedicado si es necesario. En cualquier caso, verifique que aparezcan en Propietarios y que su rol sea Puede editar (propietario) en los detalles del flujo.

  • Elimine las comparticiones redundantes o no autorizadas: durante este proceso, aproveche la oportunidad para limpiar. Si se agregó alguien por si acaso, pero nunca usa el flujo, elimínelo. El principio de privilegio mínimo ayuda a reducir la vigilancia. Asegúrese de que la lista de Propietarios de cada flujo se limite a aquellos que realmente necesitan acceso de diseño y edición.

Comunique el cambio a los usuarios afectados

Si va a quitar el acceso de alguien o a modificar la forma en que invoca un flujo, hágaselo saber. Desde la perspectiva del usuario, ejecutar un flujo a través del acceso de solo ejecución puede ser ligeramente diferente. Es posible que obtengan un vínculo compartido o vean el flujo en Flujos de equipo en lugar de Mis flujos. Explique que "Para cumplir con las nuevas directivas de Power Automate, actualizamos el método de uso compartido para Flow X. Puede continuar ejecutándolo con el método Y, pero ya no se muestra bajo su propiedad directa". Esto evita confusiones.

Verificar el estado posterior al ajuste

Después de realizar cambios, use PowerShell o el centro de administración de Power Platform para verificar que no queden flujos con propietarios externos. Por ejemplo, vuelva a ejecutar el script de identificación y confirme que ya no marca esos flujos. Resuelva cada instancia marcada mediante la eliminación o la pertenencia adecuada al entorno.

Al realizar estos ajustes, se asegura de que cuando Microsoft active el interruptor, esos flujos continúen ejecutándose para los usuarios previstos. En lugar de que un error diga you do not have access to this flow, el usuario sigue estando autorizado porque ahora es un miembro del entorno en una capacidad adecuada. Básicamente, está alineando sus prácticas de intercambio con el modelo de gobernanza de la plataforma.