flowstudio-power-automate-governance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Power Automate Governance with FlowStudio MCP

基于FlowStudio MCP的Power Automate治理

Classify, tag, and govern Power Automate flows at scale through the FlowStudio MCP cached store — without Dataverse, without the CoE Starter Kit, and without the Power Automate portal.
This skill uses
update_store_flow
to write governance metadata and the monitoring tools (
list_store_flows
,
get_store_flow
,
list_store_makers
, etc.) to read tenant state. For monitoring and health-check workflows, see the
flowstudio-power-automate-monitoring
skill.
Start every session with
tools/list
to confirm tool names and parameters. This skill covers workflows and patterns — things
tools/list
cannot tell you. If this document disagrees with
tools/list
or a real API response, the API wins.

通过FlowStudio MCP 缓存存储,你可以大规模对Power Automate流进行分类、打标签和治理——无需Dataverse、无需CoE Starter Kit、也无需访问Power Automate门户。
本技能使用
update_store_flow
写入治理元数据,使用监控工具(
list_store_flows
get_store_flow
list_store_makers
等)读取租户状态。如果你需要监控和健康检查工作流,请参考
flowstudio-power-automate-monitoring
技能。
每个会话都请先执行
tools/list
确认工具名称和参数。本技能覆盖了
tools/list
无法提供的工作流和最佳实践,如果本文档与
tools/list
或实际API返回结果冲突,请以API为准。

Critical: How to Extract Flow IDs

关键说明:如何提取流ID

list_store_flows
returns
id
in format
<environmentId>.<flowId>
. You must split on the first
.
to get
environmentName
and
flowName
for all other tools:
id = "Default-<envGuid>.<flowGuid>"
environmentName = "Default-<envGuid>"    (everything before first ".")
flowName = "<flowGuid>"                  (everything after first ".")
Also: skip entries that have no
displayName
or have
state=Deleted
— these are sparse records or flows that no longer exist in Power Automate. If a deleted flow has
monitor=true
, suggest disabling monitoring (
update_store_flow
with
monitor=false
) to free up a monitoring slot (standard plan includes 20).

list_store_flows
返回的
id
格式为
<environmentId>.<flowId>
你必须按第一个
.
分割
,才能获取其他工具所需的
environmentName
flowName
id = "Default-<envGuid>.<flowGuid>"
environmentName = "Default-<envGuid>"    (第一个「.」之前的所有内容)
flowName = "<flowGuid>"                  (第一个「.」之后的所有内容)
另外:请跳过没有
displayName
state=Deleted
的条目——这些是稀疏记录或已经在Power Automate中删除的流。如果已删除的流
monitor=true
,建议关闭监控(调用
update_store_flow
设置
monitor=false
)以释放监控配额(标准版方案包含20个监控名额)。

The Write Tool:
update_store_flow

写入工具:
update_store_flow

update_store_flow
writes governance metadata to the Flow Studio cache only — it does NOT modify the flow in Power Automate. These fields are not visible via
get_live_flow
or the PA portal. They exist only in the Flow Studio store and are used by Flow Studio's scanning pipeline and notification rules.
This means:
  • ownerTeam
    /
    supportEmail
    — sets who Flow Studio considers the governance contact. Does NOT change the actual PA flow owner.
  • rule_notify_email
    — sets who receives Flow Studio failure/missing-run notifications. Does NOT change Microsoft's built-in flow failure alerts.
  • monitor
    /
    critical
    /
    businessImpact
    — Flow Studio classification only. Power Automate has no equivalent fields.
Merge semantics — only fields you provide are updated. Returns the full updated record (same shape as
get_store_flow
).
Required parameters:
environmentName
,
flowName
. All other fields optional.
update_store_flow
仅向Flow Studio缓存写入治理元数据——它不会修改Power Automate中的实际流。这些字段无法通过
get_live_flow
或PA门户查看,仅存在于Flow Studio存储中,供Flow Studio的扫描管道和通知规则使用。
这意味着:
  • ownerTeam
    /
    supportEmail
    — 仅设置Flow Studio识别的治理联系人,不会修改PA流的实际所有者。
  • rule_notify_email
    — 仅设置接收Flow Studio故障/缺失运行通知的对象,不会修改微软内置的流故障告警。
  • monitor
    /
    critical
    /
    businessImpact
    — 仅为Flow Studio的分类字段,Power Automate没有对应字段。
合并语义:仅更新你传入的字段,返回完整的更新后记录(格式与
get_store_flow
一致)。
必填参数:
environmentName
flowName
,其余所有字段为选填。

Settable Fields

可设置字段

FieldTypePurpose
monitor
boolEnable run-level scanning (standard plan: 20 flows included)
rule_notify_onfail
boolSend email notification on any failed run
rule_notify_onmissingdays
numberSend notification when flow hasn't run in N days (0 = disabled)
rule_notify_email
stringComma-separated notification recipients
description
stringWhat the flow does
tags
stringClassification tags (also auto-extracted from description
#hashtags
)
businessImpact
stringLow / Medium / High / Critical
businessJustification
stringWhy the flow exists, what process it automates
businessValue
stringBusiness value statement
ownerTeam
stringAccountable team
ownerBusinessUnit
stringBusiness unit
supportGroup
stringSupport escalation group
supportEmail
stringSupport contact email
critical
boolDesignate as business-critical
tier
stringStandard or Premium
security
stringSecurity classification or notes
Caution with
security
:
The
security
field on
get_store_flow
contains structured JSON (e.g.
{"triggerRequestAuthenticationType":"All"}
). Writing a plain string like
"reviewed"
will overwrite this. To mark a flow as security-reviewed, use
tags
instead.

字段类型用途
monitor
布尔值启用运行级扫描(标准版方案包含20个流的配额)
rule_notify_onfail
布尔值任何运行失败时发送邮件通知
rule_notify_onmissingdays
数字当流N天未运行时发送通知(0=关闭该功能)
rule_notify_email
字符串逗号分隔的通知接收人列表
description
字符串流的功能说明
tags
字符串分类标签(也会从description的
#hashtag
中自动提取)
businessImpact
字符串低/中/高/关键
businessJustification
字符串流存在的原因、自动化的业务流程
businessValue
字符串业务价值说明
ownerTeam
字符串负责团队
ownerBusinessUnit
字符串所属业务单元
supportGroup
字符串支持升级组
supportEmail
字符串支持联系人邮箱
critical
布尔值标记为业务关键流
tier
字符串标准版或高级版
security
字符串安全分类或备注
security
字段注意事项:
get_store_flow
返回的
security
字段为结构化JSON(例如
{"triggerRequestAuthenticationType":"All"}
),如果写入
"reviewed"
这类普通字符串会覆盖原有结构。如果要标记流已完成安全评审,请使用
tags
字段。

Governance Workflows

治理工作流

1. Compliance Detail Review

1. 合规详情评审

Identify flows missing required governance metadata — the equivalent of the CoE Starter Kit's Developer Compliance Center.
1. Ask the user which compliance fields they require
   (or use their organization's existing governance policy)
2. list_store_flows
3. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Check which required fields are missing or empty
4. Report non-compliant flows with missing fields listed
5. For each non-compliant flow:
   - Ask the user for values
   - update_store_flow(environmentName, flowName, ...provided fields)
Fields available for compliance checks:
FieldExample policy
description
Every flow should be documented
businessImpact
Classify as Low / Medium / High / Critical
businessJustification
Required for High/Critical impact flows
ownerTeam
Every flow should have an accountable team
supportEmail
Required for production flows
monitor
Required for critical flows (note: standard plan includes 20 monitored flows)
rule_notify_onfail
Recommended for monitored flows
critical
Designate business-critical flows
Each organization defines their own compliance rules. The fields above are suggestions based on common Power Platform governance patterns (CoE Starter Kit). Ask the user what their requirements are before flagging flows as non-compliant.
Tip: Flows created or updated via MCP already have
description
(auto-appended by
update_live_flow
). Flows created manually in the Power Automate portal are the ones most likely missing governance metadata.
识别缺失必填治理元数据的流,功能等同于CoE Starter Kit的开发者合规中心。
1. 询问用户需要哪些合规字段(或使用其组织现有治理政策)
2. 调用list_store_flows
3. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 检查哪些必填字段缺失或为空
4. 输出不合规流列表及缺失的字段
5. 针对每个不合规流:
   - 询问用户对应字段值
   - 调用update_store_flow(environmentName, flowName, ...用户提供的字段)
可用于合规检查的字段:
字段示例政策
description
所有流都需要填写文档说明
businessImpact
必须分类为低/中/高/关键
businessJustification
高/关键影响的流必须填写
ownerTeam
所有流必须绑定负责团队
supportEmail
生产环境流必须填写
monitor
关键流必须开启监控(注意:标准版方案包含20个监控流配额)
rule_notify_onfail
建议监控流开启该功能
critical
标记业务关键流
每个组织的合规规则自行定义,以上字段是基于通用Power Platform治理模式(CoE Starter Kit)的建议。在标记流为不合规前,请先确认用户的具体要求。
提示: 通过MCP创建或更新的流已经自动通过
update_live_flow
添加了
description
,在Power Automate门户手动创建的流最容易缺失治理元数据。

2. Orphaned Resource Detection

2. 孤儿资源检测

Find flows owned by deleted or disabled Azure AD accounts.
1. list_store_makers
2. Filter where deleted=true AND ownerFlowCount > 0
   Note: deleted makers have NO displayName/mail — record their id (AAD OID)
3. list_store_flows → collect all flows
4. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Parse owners: json.loads(record["owners"])
   - Check if any owner principalId matches an orphaned maker id
5. Report orphaned flows: maker id, flow name, flow state
6. For each orphaned flow:
   - Reassign governance: update_store_flow(environmentName, flowName,
       ownerTeam="NewTeam", supportEmail="new-owner@contoso.com")
   - Or decommission: set_store_flow_state(environmentName, flowName,
       state="Stopped")
update_store_flow
updates governance metadata in the cache only. To transfer actual PA ownership, an admin must use the Power Platform admin center or PowerShell.
Note: Many orphaned flows are system-generated (created by
DataverseSystemUser
accounts for SLA monitoring, knowledge articles, etc.). These were never built by a person — consider tagging them rather than reassigning.
Coverage: This workflow searches the cached store only, not the live PA API. Flows created after the last scan won't appear.
查找归属于已删除或禁用Azure AD账号的流。
1. 调用list_store_makers
2. 筛选deleted=true且ownerFlowCount > 0的条目
   注意:已删除的开发者没有displayName/mail,记录其id(AAD OID)即可
3. 调用list_store_flows收集所有流
4. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 解析所有者:json.loads(record["owners"])
   - 检查是否有所有者的principalId匹配孤儿开发者的id
5. 输出孤儿流列表:开发者id、流名称、流状态
6. 针对每个孤儿流:
   - 重新分配治理权限:调用update_store_flow(environmentName, flowName,
       ownerTeam="新团队", supportEmail="new-owner@contoso.com")
   - 或下线:调用set_store_flow_state(environmentName, flowName,
       state="Stopped")
update_store_flow
仅更新缓存中的治理元数据,要转移PA流的实际所有权,管理员需要使用Power Platform管理中心或PowerShell操作。
注意: 很多孤儿流是系统生成的(由
DataverseSystemUser
账号创建,用于SLA监控、知识文章等场景),这类流并非人工构建,建议优先打标记而非重新分配。
覆盖范围: 本工作流仅搜索缓存存储,不查询PA实时API,上次扫描后创建的流不会出现在结果中。

3. Archive Score Calculation

3. 归档评分计算

Compute an inactivity score (0-7) per flow to identify safe cleanup candidates. Aligns with the CoE Starter Kit's archive scoring.
1. list_store_flows
2. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
3. Compute archive score (0-7), add 1 point for each:
   +1  lastModifiedTime within 24 hours of createdTime
   +1  displayName contains "test", "demo", "copy", "temp", or "backup"
       (case-insensitive)
   +1  createdTime is more than 12 months ago
   +1  state is "Stopped" or "Suspended"
   +1  json.loads(owners) is empty array []
   +1  runPeriodTotal = 0 (never ran or no recent runs)
   +1  parse json.loads(complexity) → actions < 5
4. Classify:
   Score 5-7: Recommend archive — report to user for confirmation
   Score 3-4: Flag for review →
     Read existing tags from get_store_flow response, append #archive-review
     update_store_flow(environmentName, flowName, tags="<existing> #archive-review")
   Score 0-2: Active, no action
5. For user-confirmed archives:
   set_store_flow_state(environmentName, flowName, state="Stopped")
   Read existing tags, append #archived
   update_store_flow(environmentName, flowName, tags="<existing> #archived")
What "archive" means: Power Automate has no native archive feature. Archiving via MCP means: (1) stop the flow so it can't run, and (2) tag it
#archived
so it's discoverable for future cleanup. Actual deletion requires the Power Automate portal or admin PowerShell — it cannot be done via MCP tools.
为每个流计算0-7的不活跃度评分,识别可安全清理的候选流,对齐CoE Starter Kit的归档评分逻辑。
1. 调用list_store_flows
2. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
3. 计算归档评分(0-7),满足以下条件每项加1分:
   +1  lastModifiedTime与createdTime相差不超过24小时
   +1  displayName包含「test」、「demo」、「copy」、「temp」或「backup」(不区分大小写)
   +1  createdTime距今超过12个月
   +1  state为「Stopped」或「Suspended」
   +1  json.loads(owners)为空数组[]
   +1  runPeriodTotal = 0(从未运行或近期无运行记录)
   +1  解析json.loads(complexity) → actions < 5
4. 分类处理:
   评分5-7:建议归档,提交用户确认
   评分3-4:标记待评审 →
     从get_store_flow返回结果读取现有标签,追加#archive-review
     调用update_store_flow(environmentName, flowName, tags="<现有标签> #archive-review")
   评分0-2:活跃流,无需操作
5. 针对用户确认归档的流:
   调用set_store_flow_state(environmentName, flowName, state="Stopped")
   读取现有标签,追加#archived
   调用update_store_flow(environmentName, flowName, tags="<现有标签> #archived")
「归档」的定义: Power Automate没有原生归档功能,通过MCP归档指:(1) 停止流运行,(2) 打
#archived
标签便于后续清理。实际删除需要通过Power Automate门户或管理员PowerShell操作,无法通过MCP工具完成。

4. Connector Audit

4. 连接器审计

Audit which connectors are in use across monitored flows. Useful for DLP impact analysis and premium license planning.
1. list_store_flows(monitor=true)
   (scope to monitored flows — auditing all 1000+ flows is expensive)
2. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Parse connections: json.loads(record["connections"])
     Returns array of objects with apiName, apiId, connectionName
   - Note the flow-level tier field ("Standard" or "Premium")
3. Build connector inventory:
   - Which apiNames are used and by how many flows
   - Which flows have tier="Premium" (premium connector detected)
   - Which flows use HTTP connectors (apiName contains "http")
   - Which flows use custom connectors (non-shared_ prefix apiNames)
4. Report inventory to user
   - For DLP analysis: user provides their DLP policy connector groups,
     agent cross-references against the inventory
Scope to monitored flows. Each flow requires a
get_store_flow
call to read the
connections
JSON. Standard plans have ~20 monitored flows — manageable. Auditing all flows in a large tenant (1000+) would be very expensive in API calls.
list_store_connections
returns connection instances (who created which connection) but NOT connector types per flow. Use it for connection counts per environment, not for the connector audit.
DLP policy definitions are not available via MCP. The agent builds the connector inventory; the user provides the DLP classification to cross-reference against.
审计监控流中使用的连接器,可用于DLP影响分析和高级版许可规划。
1. 调用list_store_flows(monitor=true)
   (限定监控流范围——审计1000+个全量流成本很高)
2. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 解析连接:json.loads(record["connections"])
     返回包含apiName、apiId、connectionName的对象数组
   - 记录流层级的tier字段(「Standard」或「Premium」)
3. 构建连接器清单:
   - 用到的apiName列表及对应流数量
   - tier="Premium"的流列表(检测到高级连接器)
   - 使用HTTP连接器的流列表(apiName包含「http」)
   - 使用自定义连接器的流列表(apiName没有shared_前缀)
4. 向用户输出清单
   - 如需DLP分析:用户提供DLP政策连接器分组,agent与清单交叉比对即可
限定为监控流范围。 每个流都需要调用
get_store_flow
读取
connections
JSON,标准版方案大约有20个监控流,可轻松处理。如果审计大型租户的全量流(1000+),API调用成本会非常高。
list_store_connections
返回连接实例(谁创建了哪个连接),但不返回每个流的连接器类型,可用于统计每个环境的连接数量,不适合用于连接器审计。
DLP政策定义无法通过MCP获取,agent仅负责构建连接器清单,用户提供DLP分类后再做交叉比对。

5. Notification Rule Management

5. 通知规则管理

Configure monitoring and alerting for flows at scale.
Enable failure alerts on all critical flows:
1. list_store_flows(monitor=true)
2. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - If critical=true AND rule_notify_onfail is not true:
     update_store_flow(environmentName, flowName,
       rule_notify_onfail=true,
       rule_notify_email="oncall@contoso.com")
   - If NO flows have critical=true: this is a governance finding.
     Recommend the user designate their most important flows as critical
     using update_store_flow(critical=true) before configuring alerts.

Enable missing-run detection for scheduled flows:
1. list_store_flows(monitor=true)
2. For each flow where triggerType="Recurrence" (available on list response):
   - Skip flows with state="Stopped" or "Suspended" (not expected to run)
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - If rule_notify_onmissingdays is 0 or not set:
     update_store_flow(environmentName, flowName,
       rule_notify_onmissingdays=2)
critical
,
rule_notify_onfail
, and
rule_notify_onmissingdays
are only available from
get_store_flow
, not from
list_store_flows
. The list call pre-filters to monitored flows; the detail call checks the notification fields.
Monitoring limit: The standard plan (FlowStudio for Teams / MCP Pro+) includes 20 monitored flows. Before bulk-enabling
monitor=true
, check how many flows are already monitored:
len(list_store_flows(monitor=true))
大规模配置流的监控和告警规则。
为所有关键流开启故障告警:
1. 调用list_store_flows(monitor=true)
2. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 如果critical=true且rule_notify_onfail不为true:
     调用update_store_flow(environmentName, flowName,
       rule_notify_onfail=true,
       rule_notify_email="oncall@contoso.com")
   - 如果没有任何流的critical=true:属于治理发现项,建议用户先通过update_store_flow(critical=true)标记最重要的流,再配置告警。

为定时流开启运行缺失检测:
1. 调用list_store_flows(monitor=true)
2. 遍历所有triggerType="Recurrence"的流(列表返回中可获取该字段):
   - 跳过state="Stopped"或「Suspended」的流(无运行预期)
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 如果rule_notify_onmissingdays为0或未设置:
     调用update_store_flow(environmentName, flowName,
       rule_notify_onmissingdays=2)
critical
rule_notify_onfail
rule_notify_onmissingdays
仅可通过
get_store_flow
获取,
list_store_flows
不返回这些字段。列表调用先过滤监控流,详情调用再检查通知字段。
监控配额限制: 标准版方案(FlowStudio for Teams / MCP Pro+)包含20个监控流配额,批量开启
monitor=true
前,请先检查已监控的流数量:
len(list_store_flows(monitor=true))

6. Classification and Tagging

6. 分类与打标签

Bulk-classify flows by connector type, business function, or risk level.
Auto-tag by connector:
1. list_store_flows
2. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Parse connections: json.loads(record["connections"])
   - Build tags from apiName values:
     shared_sharepointonline → #sharepoint
     shared_teams → #teams
     shared_office365 → #email
     Custom connectors → #custom-connector
     HTTP-related connectors → #http-external
   - Read existing tags from get_store_flow response, append new tags
   - update_store_flow(environmentName, flowName,
       tags="<existing tags> #sharepoint #teams")
Two tag systems: Tags shown in
list_store_flows
are auto-extracted from the flow's
description
field (e.g. a maker writes
#operations
in the PA portal description). Tags set via
update_store_flow(tags=...)
write to a separate field in the Azure Table cache. They are independent — writing store tags does not touch the description, and editing the description in the portal does not affect store tags.
Tag merge:
update_store_flow(tags=...)
overwrites the store tags field. To avoid losing tags from other workflows, read the current store tags from
get_store_flow
first, append new ones, then write back.
get_store_flow
already has a
tier
field (Standard/Premium) computed by the scanning pipeline. Only use
update_store_flow(tier=...)
if you need to override it.
按连接器类型、业务功能或风险等级批量对流分类。
按连接器自动打标签:
1. 调用list_store_flows
2. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 解析连接:json.loads(record["connections"])
   - 从apiName值生成标签:
     shared_sharepointonline → #sharepoint
     shared_teams → #teams
     shared_office365 → #email
     自定义连接器 → #custom-connector
     HTTP相关连接器 → #http-external
   - 从get_store_flow返回结果读取现有标签,追加新标签
   - 调用update_store_flow(environmentName, flowName,
       tags="<现有标签> #sharepoint #teams")
两套标签系统:
list_store_flows
中展示的标签是从流的
description
字段自动提取的(例如开发者在PA门户描述中写
#operations
)。通过
update_store_flow(tags=...)
设置的标签写入Azure Table缓存的独立字段,两者相互独立:写入存储标签不会修改描述,在门户中编辑描述也不会影响存储标签。
标签合并逻辑:
update_store_flow(tags=...)
会覆盖存储标签字段,为避免丢失其他工作流添加的标签,请先从
get_store_flow
读取当前存储标签,追加新标签后再写回。
get_store_flow
已包含扫描管道计算的
tier
字段(标准版/高级版),仅当需要覆盖该值时才调用
update_store_flow(tier=...)

7. Maker Offboarding

7. 开发者账号下架

When an employee leaves, identify their flows and apps, and reassign Flow Studio governance contacts and notification recipients.
1. get_store_maker(makerKey="<departing-user-aad-oid>")
   → check ownerFlowCount, ownerAppCount, deleted status
2. list_store_flows → collect all flows
3. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Parse owners: json.loads(record["owners"])
   - If any principalId matches the departing user's OID → flag
4. list_store_power_apps → filter where ownerId matches the OID
5. For each flagged flow:
   - Check runPeriodTotal and runLast — is it still active?
   - If keeping:
     update_store_flow(environmentName, flowName,
       ownerTeam="NewTeam", supportEmail="new-owner@contoso.com")
   - If decommissioning:
     set_store_flow_state(environmentName, flowName, state="Stopped")
     Read existing tags, append #decommissioned
     update_store_flow(environmentName, flowName, tags="<existing> #decommissioned")
6. Report: flows reassigned, flows stopped, apps needing manual reassignment
What "reassign" means here:
update_store_flow
changes who Flow Studio considers the governance contact and who receives Flow Studio notifications. It does NOT transfer the actual Power Automate flow ownership — that requires the Power Platform admin center or PowerShell. Also update
rule_notify_email
so failure notifications go to the new team instead of the departing employee's email.
Power Apps ownership cannot be changed via MCP tools. Report them for manual reassignment in the Power Apps admin center.
当员工离职时,识别其创建的流和应用,重新分配Flow Studio治理联系人和通知接收人。
1. 调用get_store_maker(makerKey="<离职用户AAD OID>")
   → 检查ownerFlowCount、ownerAppCount、deleted状态
2. 调用list_store_flows收集所有流
3. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 解析所有者:json.loads(record["owners"])
   - 如果任意principalId匹配离职用户的OID → 标记
4. 调用list_store_power_apps → 过滤ownerId匹配该OID的条目
5. 针对每个标记的流:
   - 检查runPeriodTotal和runLast,确认是否仍在活跃运行
   - 如果保留:
     调用update_store_flow(environmentName, flowName,
       ownerTeam="新团队", supportEmail="new-owner@contoso.com")
   - 如果下线:
     调用set_store_flow_state(environmentName, flowName, state="Stopped")
     读取现有标签,追加#decommissioned
     调用update_store_flow(environmentName, flowName, tags="<现有标签> #decommissioned")
6. 输出报告:已重新分配的流、已停止的流、需要手动重新分配的应用
此处「重新分配」的定义:
update_store_flow
仅修改Flow Studio识别的治理联系人和Flow Studio通知接收人,不会转移Power Automate流的实际所有权——该操作需要通过Power Platform管理中心或PowerShell完成。同时请更新
rule_notify_email
,确保故障通知发送到新团队而非离职员工邮箱。
Power Apps所有权无法通过MCP工具修改,请输出清单,提示用户在Power Apps管理中心手动重新分配。

8. Security Review

8. 安全评审

Review flows for potential security concerns using cached store data.
1. list_store_flows(monitor=true)
2. For each flow (skip entries without displayName or state=Deleted):
   - Split id → environmentName, flowName
   - get_store_flow(environmentName, flowName)
   - Parse security: json.loads(record["security"])
   - Parse connections: json.loads(record["connections"])
   - Read sharingType directly (top-level field, NOT inside security JSON)
3. Report findings to user for review
4. For reviewed flows:
   Read existing tags, append #security-reviewed
   update_store_flow(environmentName, flowName, tags="<existing> #security-reviewed")
   Do NOT overwrite the security field — it contains structured auth data
Fields available for security review:
FieldWhereWhat it tells you
security.triggerRequestAuthenticationType
security JSON
"All"
= HTTP trigger accepts unauthenticated requests
sharingType
top-level
"Coauthor"
= shared with co-authors for editing
connections
connections JSONWhich connectors the flow uses (check for HTTP, custom)
referencedResources
JSON stringSharePoint sites, Teams channels, external URLs the flow accesses
tier
top-level
"Premium"
= uses premium connectors
Each organization decides what constitutes a security concern. For example, an unauthenticated HTTP trigger is expected for webhook receivers (Stripe, GitHub) but may be a risk for internal flows. Review findings in context before flagging.
使用缓存存储数据评审流的潜在安全风险。
1. 调用list_store_flows(monitor=true)
2. 遍历每个流(跳过无displayName或state=Deleted的条目):
   - 分割id得到environmentName、flowName
   - 调用get_store_flow(environmentName, flowName)
   - 解析安全配置:json.loads(record["security"])
   - 解析连接:json.loads(record["connections"])
   - 直接读取顶层字段sharingType(不在security JSON内部)
3. 向用户输出发现项供评审
4. 针对已评审的流:
   读取现有标签,追加#security-reviewed
   调用update_store_flow(environmentName, flowName, tags="<现有标签> #security-reviewed")
   请勿覆盖security字段——它包含结构化认证数据
可用于安全评审的字段:
字段位置说明
security.triggerRequestAuthenticationType
security JSON
"All"
= HTTP触发器接受未认证请求
sharingType
顶层字段
"Coauthor"
= 共享给协作者编辑
connections
connections JSON流使用的连接器(检查HTTP、自定义连接器)
referencedResources
JSON字符串流访问的SharePoint站点、Teams频道、外部URL
tier
顶层字段
"Premium"
= 使用高级连接器
每个组织对安全风险的定义不同,例如未认证HTTP触发器对于webhook接收方(Stripe、GitHub)是预期配置,但对于内部流可能存在风险,请结合上下文评审后再标记风险。

9. Environment Governance

9. 环境治理

Audit environments for compliance and sprawl.
1. list_store_environments
   Skip entries without displayName (tenant-level metadata rows)
2. Flag:
   - Developer environments (sku="Developer") — should be limited
   - Non-managed environments (isManagedEnvironment=false) — less governance
   - Note: isAdmin=false means the current service account lacks admin
     access to that environment, not that the environment has no admin
3. list_store_flows → group by environmentName
   - Flow count per environment
   - Failure rate analysis: runPeriodFailRate is on the list response —
     no need for per-flow get_store_flow calls
4. list_store_connections → group by environmentName
   - Connection count per environment
审计环境的合规性和资源蔓延情况。
1. 调用list_store_environments
   跳过无displayName的条目(租户层级元数据行)
2. 标记以下情况:
   - 开发者环境(sku="Developer")——应该限制数量
   - 非托管环境(isManagedEnvironment=false)——治理能力较弱
   - 注意:isAdmin=false表示当前服务账号缺少该环境的管理员权限,不代表环境没有管理员
3. 调用list_store_flows → 按environmentName分组
   - 每个环境的流数量
   - 故障率分析:列表返回中已包含runPeriodFailRate,无需逐流调用get_store_flow
4. 调用list_store_connections → 按environmentName分组
   - 每个环境的连接数量

10. Governance Dashboard

10. 治理仪表盘

Generate a tenant-wide governance summary.
Efficient metrics (list calls only):
1. total_flows = len(list_store_flows())
2. monitored = len(list_store_flows(monitor=true))
3. with_onfail = len(list_store_flows(rule_notify_onfail=true))
4. makers = list_store_makers()
   → active = count where deleted=false
   → orphan_count = count where deleted=true AND ownerFlowCount > 0
5. apps = list_store_power_apps()
   → widely_shared = count where sharedUsersCount > 3
6. envs = list_store_environments() → count, group by sku
7. conns = list_store_connections() → count

Compute from list data:
- Monitoring %: monitored / total_flows
- Notification %: with_onfail / monitored
- Orphan count: from step 4
- High-risk count: flows with runPeriodFailRate > 0.2 (on list response)

Detailed metrics (require get_store_flow per flow — expensive for large tenants):
- Compliance %: flows with businessImpact set / total active flows
- Undocumented count: flows without description
- Tier breakdown: group by tier field

For detailed metrics, iterate all flows in a single pass:
  For each flow from list_store_flows (skip sparse entries):
    Split id → environmentName, flowName
    get_store_flow(environmentName, flowName)
    → accumulate businessImpact, description, tier

生成租户全域的治理摘要。
高效指标(仅需列表调用):
1. total_flows = len(list_store_flows())
2. monitored = len(list_store_flows(monitor=true))
3. with_onfail = len(list_store_flows(rule_notify_onfail=true))
4. makers = list_store_makers()
   → active = deleted=false的数量
   → orphan_count = deleted=true且ownerFlowCount > 0的数量
5. apps = list_store_power_apps()
   → widely_shared = sharedUsersCount > 3的数量
6. envs = list_store_environments() → 计数,按sku分组
7. conns = list_store_connections() → 计数

从列表数据计算:
- 监控覆盖率:monitored / total_flows
- 通知配置率:with_onfail / monitored
- 孤儿资源数:来自步骤4
- 高风险流数:runPeriodFailRate > 0.2的流(列表返回中可获取)

详细指标(需要逐流调用get_store_flow——大型租户成本很高):
- 合规率:设置了businessImpact的流 / 总活跃流数
- 未文档化流数:无description的流
- 版本分布:按tier字段分组

如需详细指标,请单轮遍历所有流:
  遍历list_store_flows返回的所有流(跳过稀疏条目):
    分割id → environmentName, flowName
    调用get_store_flow(environmentName, flowName)
    → 累计businessImpact、description、tier

Field Reference:
get_store_flow
Fields Used in Governance

字段参考:治理中用到的
get_store_flow
字段

All fields below are confirmed present on the
get_store_flow
response. Fields marked with
*
are also available on
list_store_flows
(cheaper).
FieldTypeGovernance use
displayName
*
stringArchive score (test/demo name detection)
state
*
stringArchive score, lifecycle management
tier
stringLicense audit (Standard vs Premium)
monitor
*
boolIs this flow being actively monitored?
critical
boolBusiness-critical designation (settable via update_store_flow)
businessImpact
stringCompliance classification
businessJustification
stringCompliance attestation
ownerTeam
stringOwnership accountability
supportEmail
stringEscalation contact
rule_notify_onfail
boolFailure alerting configured?
rule_notify_onmissingdays
numberSLA monitoring configured?
rule_notify_email
stringAlert recipients
description
stringDocumentation completeness
tags
stringClassification —
list_store_flows
shows description-extracted hashtags only; store tags written by
update_store_flow
require
get_store_flow
to read back
runPeriodTotal
*
numberActivity level
runPeriodFailRate
*
numberHealth status
runLast
ISO stringLast run timestamp
scanned
ISO stringData freshness
deleted
boolLifecycle tracking
createdTime
*
ISO stringArchive score (age)
lastModifiedTime
*
ISO stringArchive score (staleness)
owners
JSON stringOrphan detection, ownership audit — parse with json.loads()
connections
JSON stringConnector audit, tier — parse with json.loads()
complexity
JSON stringArchive score (simplicity) — parse with json.loads()
security
JSON stringAuth type audit — parse with json.loads(), contains
triggerRequestAuthenticationType
sharingType
stringOversharing detection (top-level, NOT inside security)
referencedResources
JSON stringURL audit — parse with json.loads()

以下所有字段均确认存在于
get_store_flow
返回结果中,标有
*
的字段也可从
list_store_flows
获取(成本更低)。
字段类型治理用途
displayName
*
字符串归档评分(检测测试/演示类名称)
state
*
字符串归档评分、生命周期管理
tier
字符串许可审计(标准版vs高级版)
monitor
*
布尔值该流是否正在被主动监控?
critical
布尔值业务关键流标记(可通过update_store_flow设置)
businessImpact
字符串合规分类
businessJustification
字符串合规证明
ownerTeam
字符串所有权问责
supportEmail
字符串升级联系人
rule_notify_onfail
布尔值是否已配置故障告警?
rule_notify_onmissingdays
数字是否已配置SLA监控?
rule_notify_email
字符串告警接收人
description
字符串文档完整性
tags
字符串分类——
list_store_flows
仅展示从描述提取的hashtag;通过
update_store_flow
写入的存储标签需要调用
get_store_flow
才能读取
runPeriodTotal
*
数字活跃度
runPeriodFailRate
*
数字健康状态
runLast
ISO字符串上次运行时间戳
scanned
ISO字符串数据新鲜度
deleted
布尔值生命周期追踪
createdTime
*
ISO字符串归档评分(存续时长)
lastModifiedTime
*
ISO字符串归档评分(更新新鲜度)
owners
JSON字符串孤儿检测、所有权审计——用json.loads()解析
connections
JSON字符串连接器审计、版本——用json.loads()解析
complexity
JSON字符串归档评分(复杂度)——用json.loads()解析
security
JSON字符串认证类型审计——用json.loads()解析,包含
triggerRequestAuthenticationType
sharingType
字符串过度共享检测(顶层字段,不在security内部)
referencedResources
JSON字符串URL审计——用json.loads()解析

Related Skills

相关技能

  • flowstudio-power-automate-monitoring
    — Health checks, failure rates, inventory (read-only)
  • flowstudio-power-automate-mcp
    — Core connection setup, live tool reference
  • flowstudio-power-automate-debug
    — Deep diagnosis with action-level inputs/outputs
  • flowstudio-power-automate-build
    — Build and deploy flow definitions
  • flowstudio-power-automate-monitoring
    — 健康检查、故障率、清单(只读)
  • flowstudio-power-automate-mcp
    — 核心连接配置、实时工具参考
  • flowstudio-power-automate-debug
    — 操作级输入/输出深度诊断
  • flowstudio-power-automate-build
    — 流定义构建与部署