Approval 节点
审批节点该怎么放、给谁批、为什么会卡住。
严格来说，Approval 更像“人类收口节点”，不完全等于普通 capability。
但用户在实际搭 workflow 时，最常把它和 capability 一起问，所以这里单独拆成一页。
Approval 节点到底负责什么
它负责的不是“帮你判断业务对不对”，而是：
- 在高影响动作前停下来；
- 把关键信息交给审批人看；
- 等人决定是继续还是不要继续。
它最应该放在哪
最典型的位置有三个：
- 对外提交前；
- 对外发送前；
- 写回、发布、覆盖重要结果前。
如果动作已经发生，再放审批，意义就完全变了。
审批节点里最好带什么上下文
- 这次要做什么；
- 为什么现在要做；
- 关键证据或预览；
- 影响对象是谁；
- 批准后会发生什么。
如果审批节点只写一句“是否继续”，审批人通常根本无法判断。
真实运行里最容易卡住的地方
审批节点通常要求明确审批角色，而且会在运行前或运行中等待人来决定。
所以常见卡点是：
- 审批角色没选好；
- 审批人没看到足够上下文；
- 审批通过后，后面的外部动作依然失败；
- 用户误以为“停住了”就是系统报错。
常见错误
| 现象 | 常见原因 | 更稳的处理方式 |
|---|---|---|
| 流程停住不动 | 实际是在等审批 | 先看审批列表 |
| 审批人不知道该不该批 | 审批输入太空 | 把摘要、证据、影响补进去 |
| 批准后还失败 | 审批只代表允许继续，不代表外部动作一定成功 | 继续查后续节点 |
| 审批放在最后 | 它没有真正拦住高风险动作 | 把审批前移到外部动作之前 |
更好的使用方法
- 一次审批只拦一种后果最清晰；
- 能拆开“内容复核”和“对外提交批准”就尽量拆开；
- 审批通过后最好留有证据节点或交付回执；
- 浏览器提交、外部写入、公开发布前，优先放审批。