多级审批流设计实战：条件路由、加签、代理与撤回

结论先行：一套好用的多级审批流 = 条件路由 + 四个人性化机制（加签、代理、撤回、催办）。实施经验是：先把金额、部门、岗位三类路由规则定清楚再设计节点，能减少 90% 的后期返工；漏掉代理与撤回机制，系统上线后投诉最多的一定是这两处。

审批流是所有工作流场景里上线最快、也最容易返工的一个。返工的原因很少是"流程跑不通"，而是"现实里的例外情况系统接不住"：领导出差谁来批？提交错了能不能撤？本文按实战顺序讲清四个核心机制。

Table of Contents

一、条件路由：按什么条件走哪条路

条件路由（Conditional Routing）决定"谁的申请走哪条审批线"。企业里最常用三个维度：

设计要点两条：第一，阈值必须由业务部门书面确认，不要开发拍脑袋定 5000 还是 8000；第二，条件判断用"区间互斥"写法，避免出现两个条件同时命中或都不命中的缝隙。

加签分两种：前加签是审批人处理前增加一位会签人，流程走完加签人再到原审批人；后加签是原审批人先批，再交给补充的人复核。加签要限制层级，默认最多加签 1 层，防止无限加签把流程变成击鼓传花。

代理解决"审批人不在"的问题。设计上支持两种：指定代理人在某时间段内代行审批（如休假一周），以及按组织架构自动向上找直属上级兜底。代理人审批的记录要保留原始审批人与代理人双标识，方便审计。

撤回规则三条：下一节点尚未处理前允许撤回；已进入财务打款等终态节点不允许撤回；撤回后允许修改重新提交，而不是直接作废。这三条写进产品逻辑，能挡掉一半以上的用户投诉。

把机制组合起来看一条报销流的节点设计（请假流同理，把金额阈值换成天数即可）：

以猫拽低代码（CatPull）为例，上述流程用条件分支、审批、并行、HTTP 请求、变量赋值节点即可搭出，审批人配置支持按部门主管自动解析，不需要写死具体人名，人员变动时流程不用改。

A：规则要提前配置明确。后加签为"知会"性质时以原审批人为准；前加签默认是会签（须全员同意），任一人驳回即整单驳回。冲突场景建议升级到上一级裁决，而不是系统自动取舍。

A：两层保险：代理机制里配置"按组织架构自动向上兜底"，审批人账号停用时流程自动移交其直属上级；管理端提供"流程转办"功能，管理员可手动把待办批量转给接任者。

A：由财务与业务部门共同确认，写入制度文件后再落系统，开发只负责把规则配置化。阈值变更要留版本记录，历史单据按提交时点的旧阈值执行，避免追溯争议。