从 2025 年 6 月开始，与非环境成员的用户共享的任何流都将无法被该用户访问。 此对 Power Automate 的重要更改要求用户必须是环境的成员才能访问该环境中的流程。 此更改通过强制实施环境边界来增强安全性。 但是，它会影响在不同环境中共享流的组织，例如，流所有者将环境外部的某人添加为共同所有者或仅运行用户。
为遵守新政策，Power Platform 管理员需识别与环境外用户共享的流程，并调整这些流程的共享设置。 本文提供了一种结构化的方法来实现这一点。
本文可帮助您完成以下操作：
- 识别与外部用户（不在流环境中的用户）共享的流。
- 调整这些流的共享和访问以确保连续性（例如，向环境添加适当的用户并使用仅运行访问）。
本文允许 Power Platform 管理员在 2025 年 6 月政策生效前提前解决共享问题。 它还可以帮助建立治理，以安全地管理未来的流共享。 为了说明要点，本文包括真实示例和分步说明。
在共享云端流中学习管理共享流的最佳实践。
识别与环境外部用户共享的流
第一步是清点每个环境中的所有云端流及其共享用户，然后确定哪些流程与圈外人（即非该环境成员的用户）存在共享关系。 Power Automate 流可通过两种方式创建：作为普通（非解决方案）流，或作为解决方案感知流（Dataverse 解决方案的一部分）。 两者都驻留在一个环境中，并且都需要审查。 以下各节介绍标识外部共享流的方法。
Power Platform 管理中心—GUI 方法
环境管理员可使用 Power Platform 管理中心进行可视化审核。
在 Power Platform 管理中心中，选择管理>环境>（您的环境）>资源>流。
列表中显示环境中的所有流，以及所有者列。
对于每个流，检查所有者。 如果流有多个所有者（创建者和共同所有者），则该流是共享的。 将这些所有者与环境中的已知成员进行比较。 例如，比较该环境的安全组或用户列表。
标记那些拥有者或共同拥有者不是预期环境成员的流。 例如，如果部门 A 的环境应仅包含部门 A 的用户，但您看到部门 B 的共同拥有者，则该流与外部人员共享。 您可能需要选择所有者的名称才能查看详细信息，或与环境的用户目录进行交叉引用。
Power Platform 管理中心的优势—GUI 方法
Power Platform 管理中心提供用户友好的界面，并允许按名称或拥有者过滤和排序流。 如果您知道哪些团队和用户属于该环境，则可以快速发现明显的不匹配。
Power Platform 管理中心的缺点—GUI 方法
此方法是手动的，且不适合处理大量流。 您必须单独验证所有者，这对于大型环境来说可能非常耗时。 直接从用户界面交叉检查环境成员身份可能很困难。
PowerShell 脚本 - 自动化方法
为了进行系统化和可重复的审计，Power Automate 提供了管理 PowerShell 命令来列出流及其所有者。 此方法对于跨大型环境或整个租户进行批量分析非常有用。 您可以编写流程脚本以输出所有流并突出显示外部共享。
例如，此脚本使用 Get-AdminFlow 检索所有流，然后对每个流使用 Get-AdminFlowOwnerRole 列出其所有者及其角色。 输出列出了每个流名称和 Owner: [User]、Role: [Owner/Co-owner] 的项目符号。 您可以将此输出重定向到文件或进一步处理它。
接下来，确定外部共享：将每个所有者的用户主体名称（UPN）与作为环境成员的用户集进行比较。 任何所有者的 UPN 不在环境用户列表或安全组中的情况，表示该流为外部共享。 在实践中，您可以：
- 从上一个脚本和环境用户列表中导出流所有者列表，然后使用 Excel 或脚本查找差异，或者
- 可通过
Get-AdminEnvironmentUser对 PowerShell 脚本进行增强，以与环境用户进行交叉验证。
PowerShell 脚本的优点——自动化方法
这种方法是自动化和全面的。 它可以快速枚举成百上千个流，并可编写报告脚本。 您可以按计划（例如每月）运行它，以发现新的外部共享。
PowerShell 脚本的缺点——自动化方法
需要熟悉 PowerShell 和管理员权限。 此外，原始输出显示 UPN 和对象 ID。 需要分析并判断哪些流位于环境之外，这需要一定程度的分析。 但是，如果您知道环境的用户域或有环境成员列表，则这很简单。
Center of Excellence（CoE）工具包 - 仪表板方法
如果您的组织使用了 Power Platform卓越中心入门套件，它提供了 Power BI 包含共享指标的仪表盘和报告。 CoE 的流清单可以突出显示具有来宾所有者或环境的正常安全组之外的所有者的流。 例如，卓越中心仪表盘可能包含多个所有者的流或与访客用户共享的流的报告。 您可以利用这些见解来查找共享异常的流。
卓越中心 （CoE） 工具包的优点 - 仪表板方法
集中式可视化报告，可能已经在聚合环境数据。 如果 CoE 已到位，则无需编写额外的脚本。 它可以自动标记不合规的模式。
Center of Excellence （CoE） 工具包的缺点 - 仪表板方法
需要部署 CoE 初学者工具包并使其保持最新状态。 数据可能不是实时的（通常按计划刷新）。 此外，设置自定义筛选器（如标识外部域用户）可能需要调整 CoE 组件。
鉴别方法比较
| 方法 | 工具/方法 | 优点 | 缺点 |
|---|---|---|---|
| 管理中心 (GUI) | Power Platform 管理中心网页界面：可直观查看流和所有者。 | 简单易用的界面。 对少量流的即时洞察。 | 手动验证，不适用于大型环境。 没有所有者与环境成员身份的内置交叉引用。 |
| PowerShell 脚本 | 管理 PowerShell 命令（Get-AdminFlow、Get-AdminFlowOwnerRole）。 |
流和所有者的自动批量输出。 可安排任务并导出结果至 CSV 或其他格式。 如果环境用户列表已知，则精度高。 | 需要 PowerShell 知识。 必须单独确定哪些所有者是外部的。 需要脚本或后期处理。 |
| CoE 工具包（仪表板） | Power BI 仪表盘和 CoE 流。 | 如果安装了 CoE，则已可用。 可以在集中报表中突出显示异常共享，例如外部所有者或来宾所有者。 | 需要 CoE 部署和维护。 存在数据刷新延迟（非实时）。 可能需要自定义以查明特定的外部用户。 |
使用上表中的一种或多种方法，编译具有外部共享用户的流列表。 这些是策略更改之前需要注意的受影响流。 在许多组织中，这可能是可管理的流子集，例如，只有少数跨部门流或与合作伙伴的来宾帐户共享的流。 在其他情况下，尤其是具有开放共享做法的租户，可能需要处理大量流，因此越早识别它们越好。
调整受影响流的共享和访问
确定与其环境外部的用户共享的流后，下一步是修正每个流的共享配置。 目标是确保将需要流访问权限的每个用户都正确地添加到环境中（或者以其他方式修改流的访问权限）。 这样做是为了在新的强制执行开始时，没有人会丢失功能。 以下部分描述了如何进行调整。
评估每个外部共享的必要性
对于每个已标记的流，请与流的所有者或相关业务团队讨论在外部共享该流的原因。 此上下文对于确定修复非常重要。 以下列表描述了常见场景和操作。
- 场景 1：用户被添加为共同所有者仅用于运行流或查看输出：在许多情况下，所有者添加外部用户为所有者时，该用户实际上只需触发或使用流（而非编辑流）。 例如，所有者可以将技术支持代理添加为流的共同所有者，以便他们可以手动触发流。 在这种情况下，用户可能不需要完全所有者权限。
- 操作：将其从所有者列表中移除，并改为以仅运行权限的用户身份与他们共享流（如适用），同时确保其具备环境访问权限。 这提供了运行流所需的功能，而无需将其设为所有者。 更多详情请参阅本文中的向环境添加必要用户部分。
- 场景 2：用户真正参与流的构建或维护：例如，两个部门共同开发一个流，因此将部门 B 的用户设为部门 A 环境的共同所有者。
- 操作：将该用户以适当的角色正式纳入环境作为所有者，或考虑将流程移动到中立环境，如果多个组织单位应共同拥有它。 在短期内，将用户添加到环境的允许用户列表并为他们提供适当的角色（如果他们需要编辑权限，则为环境创建者）可以解决访问问题。
- 场景 3：共享已不再需要：有时用户是临时添加的或已离开项目。
- 操作：从流的共享中移除外部用户。 如果适用，这是最简单的修复方法。 如果环境外部没有人需要该流，请取消与他们共享该流。 然后，该流符合要求，并且仅保留内部所有者。
- 场景 4：跨租户或访客用户共享：例如，流与访客（外部租户）账户共享。 此操作在强制执行后被阻止。
- 操作：确定该访客是否绝对需要访问权限。 如果需要，一个选项是正式将该访客添加为 Azure AD 访客到您的租户并加入环境的安全组。 这使他们成为环境成员。 这是不常见的情况。 或者，可以考虑将所有权转移给内部用户，以便该用户代表客人进行操作，或者使用其他机制，例如通过安全的 HTTP 触发器暴露流，而不是直接共享。 我们建议删除直接来宾共享，因为即使添加为环境成员，也可能会出现交叉租户问题。
将必要用户添加到环境中
对于应继续有权访问流的每个用户，请确保他们是今后环境的成员。 这通常意味着：
如果环境使用安全组：将用户的账户添加到该 Azure AD 安全组中。 除非另有配置，否则这将授予他们在环境中的默认基本用户角色。 对于只需要运行流而不需要创建和编辑的用户来说，基本用户角色通常就足够了。 添加后，在 Power Platform 管理中心验证用户是否已出现在环境的用户列表中。
如果这是租户默认环境，对所有用户开放：大多数已授权用户已包含其中。 确保用户拥有 Power Automate 许可证。 强制执行主要影响成员资格受限的非默认环境。
环境创建者与基本用户：除非该人员确实需要在该环境中构建和编辑流，否则不要授予环境创建者权限。 在我们的修复中，我们更愿意只提供基本用户或允许运行共享流的自定义最小角色。 对于仅运行访问，基本用户就足够了，用户不需要是 Maker。 限制 Maker 角色是一种治理最佳实践，下一节将对此进行更多讨论。
调整流的共享设置
当用户现在是环境成员时，调整与他们共享流的方式。
如果用户仅需运行流：使用仅运行共享。 在 Power Automate 中，打开流的共享设置。 从所有者列表中移除该用户，并在“仅运行用户”部分添加其名称。 对于手动触发的流（如按钮流和即时流）或通过可共享链接触发的流，这将确保用户无需成为所有者即可触发流。 他们无法编辑或显示流的内部内容，只能运行流。 结果是，用户将保留在所有者列表之外，因此不会发生环境冲突，但可以按预期使用流的功能。
示例：市场部的 Bob 曾是销售部潜在客户处理者流的共同所有者，仅用于定期启动该流。 我们将 Bob 作为共同所有者删除，并将 Bob 添加为仅运行用户。 Bob 还将作为基本用户添加到 Sales 环境中。 现在，Bob 可以选择流的按钮或接收其链接来运行它，但他不再是外部所有者，而是该环境的授权基本用户。
如果用户需要完整的所有者权限（共同编辑）：在将他们添加到环境后，确保他们在流中仍被列为所有者。 从技术上讲，您可以删除并重新添加它们以刷新权限。 但一旦他们进入环境，共享就是合法的。 如果来自不同地区的两个所有者长期维护该流，则还可以考虑将该流移动到解决方案中。 如果需要，可以更轻松地将解决方案流传输到专用环境。 无论如何，请确认他们在流程详情中显示在所有者列表中，且角色为“可编辑（所有者）”。
删除任何冗余或未经授权的共享：在此过程中，可借机进行清理。 如果添加了某人以防万一，但从未使用过该流，请将其删除。 最小权限原则有助于减少监管风险。 确保每个流的所有者列表仅包含真正需要设计和编辑权限的用户。
向受影响用户沟通变更
如果您要删除某人的访问权限或更改他们调用流的方式，请告知他们。 从用户角度来看，通过仅运行权限执行流可能略有不同。 他们可能会收到共享链接或在“团队流”而非“我的流”中看到该流。 解释称：“为遵守新 Power Automate 政策，我们更新了流 X 的共享方式。您仍可通过方法 Y 运行该流，但它不再显示在您的直接所有权下。”这可避免混淆。
验证调整后状态
在进行更改后，请使用 PowerShell 或 Power Platform 管理中心再次确认是否仍有流由外部所有者拥有。 例如，再次运行标识脚本，并确认它不再标记这些流。 通过删除或适当的环境成员身份解析每个标记的实例。
通过执行这些调整，可以确保当 Microsoft 翻转开关时，这些流继续为目标用户运行。 与显示 you do not have access to this flow 错误不同，用户仍保持授权状态，因为他们现在以适当的角色成为环境成员。 从本质上讲，您正在将共享实践与平台的治理模型保持一致。