求支持构建多受众问卷提交的后端Microsoft Flow工作流及技术答疑

核心需求梳理 #

• 触发源：Microsoft Forms的5份团队问卷提交
• 审批流转逻辑：
  1. 根据提交团队，从SharePoint列表匹配对应业务审批人，发起业务审批
  2. 业务审批通过后，从SharePoint列表匹配对应财务审批人，发起财务审批
  3. 双审批通过后生成唯一请求ID
  4. 请求ID生成后流转至后续处理团队
• 通知规则：所有流程节点向请求人推送状态；审批驳回时触发邮件通知

分步流程配置 #

步骤1：设置触发器 #

选择当有新响应提交（Microsoft Forms）作为触发动作，关联需要监听的5份问卷。若问卷需区分处理逻辑，可在后续步骤通过表单ID判断分支。

步骤2：获取提交信息与审批人匹配 #

1. 添加获取响应详情（Microsoft Forms）动作，提取提交人邮箱、提交团队等核心字段
2. 添加查找项（SharePoint）动作，以「提交团队」为匹配条件，从预先配置的审批人列表（含团队名称、业务审批人邮箱、财务审批人邮箱列）中查询对应审批人信息

步骤3：业务团队审批环节 #

1. 添加开始并等待审批动作，选择「审批-第一个待办事项」，设置审批人为SharePoint查询到的业务审批人，审批内容包含请求核心信息
2. 添加条件动作，判断审批结果：
   • 分支1（批准）：发送邮件给请求人，内容示例：业务审批已通过，流程进入财务审批环节
   • 分支2（拒绝）：发送邮件给请求人，内容示例：业务审批已驳回，请查看审批详情，并添加终止流程动作结束当前工作流

步骤4：财务团队审批环节 #

在业务审批通过的分支下，重复类似操作：

1. 添加开始并等待审批动作，审批人为SharePoint查询到的财务审批人
2. 添加条件动作判断审批结果：
   • 分支1（批准）：发送邮件给请求人，内容示例：财务审批已通过，将生成专属请求ID
   • 分支2（拒绝）：发送邮件给请求人并终止流程

步骤5：生成请求ID与后续流转 #

1. 创建变量：在流程起始位置（触发器之后）创建字符串类型变量请求ID，赋值规则可自定义（例如：{提交团队缩写}-{当前日期yyyyMMdd}-{流水号}）
   • 流水号可通过获取列表项（SharePoint）统计该团队历史请求数，自增1生成
2. 将请求ID与全部请求详情写入SharePoint请求跟踪列表
3. 发送邮件通知请求人：请求已完成双审批，专属请求ID：{请求ID}，已流转至XX处理团队
4. 触发后续团队的处理流程（例如：发布Teams通知、启动关联Flow）

变量、条件与Apply to All的场景解释 #

变量的使用场景 #

• 统一存储关键数据：如请求ID，在双审批通过后赋值，后续所有环节直接引用，避免重复生成或规则不一致
• 暂存批量数据：若某个团队对应多个审批人，可创建数组变量存储所有审批人邮箱，在审批步骤中直接引用
• 状态跟踪：创建字符串变量当前流程状态，每完成一个节点更新值（如「业务审批中」→「财务审批通过」），统一用于通知内容

条件的使用场景 #

• 审批结果分支：必须用条件区分「批准/拒绝」，分别执行流程继续或终止逻辑，同时触发对应通知
• 数据有效性校验：如SharePoint未查询到审批人时，用条件判断空值，触发管理员告警并终止流程
• 表单类型区分：若5份问卷字段差异大，用条件判断表单ID，执行不同的字段提取逻辑

Apply to All的使用场景 #

• 多审批人结果遍历：若某个环节需多人并行审批，开始并等待审批会返回多个结果，需用Apply to All遍历结果，判断是否满足通过条件
• 批量数据处理：如需将请求详情写入多个SharePoint列表，用Apply to All遍历列表名称，执行批量写入
• 多表单响应处理：若触发器同时监听多份表单且返回批量响应，用Apply to All遍历每条响应单独处理

常见问题排查（针对未完成工作流） #

• 变量初始化错误：变量需在流程起始位置创建，不能在分支内创建，否则后续步骤无法引用
• Apply to All误用：单条响应/单个审批人场景无需遍历，仅当返回数组类型数据（如多审批结果、多列表项）时使用
• SharePoint查询结果重复：确保审批人列表中「团队名称」为唯一值，避免返回多条数据导致流程异常
• 通知未触发：检查邮件收件人是否正确引用提交人邮箱，条件分支是否覆盖「批准/拒绝」所有情况

内容的提问来源于stack exchange，提问作者Lavanya Loganathan