审批流程是什么：等待决定与执行结果必须分开记录
解释申请、审批状态与批准后动作的关系，说明超时、拒绝和重复通知怎样影响可追溯流程。
先理解这个概念
审批流程是在规定环节收集有权人员决定，并依据结果继续处理任务的过程。它不仅是发送一条通知，通知已读也不等于批准；批准后动作执行失败，也不能标为业务已完成。设计时应明确申请版本、审批对象与状态，保留可核对决定，再单独确认实际执行，不能由模型猜测或替人作出授权。
申请状态与执行状态有不同证据
Power Automate 的审批功能把创建审批、等待响应和后续分支组织起来，云端流程则执行具体动作。系统应分别记录审批决定和执行失败。等待与拒绝也不能全部压成一个“处理中”。审批必须对应明确内容，申请修改后旧决定是否仍适用，需要业务规则说明。页面按钮文字或模型的判断不能代替真实审批记录。对于多人审批，所需人数和顺序也应明确，不能仅因一人同意就自动推断全部条件满足。
用模拟请求核对拒绝和超时路径
例如在测试环境提交公开样本，由预设模拟响应分别走批准与拒绝分支，检查只有符合条件时才产生测试动作。再让响应超时，核对是否保持待处理或按规则终止，不自动视为同意。重复通知应指向同一申请，不创建多份执行。本文没有发送审批、联系人员或操作真实业务系统，例子属于验收设计。最终还要查询目标状态，避免批准已经保存却后续写入失败时仍显示全部完成。
维护人员与规则变化需要版本记录
审批角色变更或申请字段调整后，重跑旧流程并核对权限来源，不能让过期配置继续替新业务作决定。保留决定记录与执行标识，失败恢复时先确认已经发生的动作，避免重复执行。成本包括等待跟进与异常处理，不只是通知次数。AI 可以帮助整理材料，却不能因为自动化存在就扩大授权范围。最终交付让申请内容、批准证据与实际结果能够对应，明确尚未获得决定的事项，而不是用一个成功图标掩盖缺失授权。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。