3.2 审批流实战：请假流程装配记

3.2 审批流实战：请假流程装配记

本节摘要：一条完整的请假审批流实战，按背景、操作、结果、解读、变式五段展开：数据建模、画布装配、条件分支、人工审批节点、试运转与返工。读完你能独立装配任何「提交、审核、归档」形态的流程，并掌握人工节点这个流程引擎里最特殊的零件。

3.1 把引擎三件套讲清了，这一节上场拧真螺丝。案例选请假审批——它是最小而完整的审批形态，麻雀虽小，五脏俱全：有提交、有分支（按天数走不同审批人）、有挂起等人的环节、有归档回写。

一、背景：行政部的一张工单

一家六十人的公司，请假流程此前跑在群聊里：员工群里说一声，主管回个「好」，人事月底翻聊天记录对考勤。三个痛点：口头批准无凭据，月底对账鸡飞狗跳；三天以上的长假该由总监把关，实际全靠主管自觉转达；请假余额（年假池）没人维护，超休全靠人事记在小本上。工单目标明确：提交留痕、按天数分级审批、余额自动扣减。这是典型的「提交、审核、归档」形态，配置工种可以全程承接。

图 3-1 请假审批流的画布连线图

二、操作：从建表到归档段

第一步建模。两张新表：请假申请表（申请人多对一用户、开始日期、结束日期、天数数字、事由多行文本、状态单选：待审批、已通过、已驳回）与年假池表（用户、当年余额数字）。年假池单独成表而不是塞在用户表，理由是维护职责归人事，权限边界要干净。第二步表单页。给申请表配一页提交表单，字段顺序按填写习惯排，天数让员工自己填、不做自动计算——第一天先跑通流程，自动算天数属于锦上添花。

第三步画布。按图 3-1 的五个工位装配。技术含量集中在两处。条件节点的表达式引用触发数据的「天数」字段：大于三天走会签支，否则走主管单签支。人工节点的受理人配置：主管单签支绑定为「申请人的部门主管」（用户表里维护的汇报关系字段），会签支在此基础上串联总监。人工节点配置的三颗关键螺丝如下：

人工节点「主管审批」配置要点：
  1. 受理人：绑定变量「申请人 → 汇报对象」，而不是写死某个名字
     ——写死人名，人员变动日就是流程失灵日
  2. 待办入口：受理人登录后在「待办中心」看到任务，附申请详情页链接
  3. 审批结果回流：通过 → 流程继续走归档段；驳回 → 进入驳回分支
  4. 超时策略：暂不设，第一版先跑人工节奏（变式二再加强化）
​

第四步归档段。通过后两颗自动螺丝：增改查节点写状态并扣余额（余额 = 原值 − 天数，变量表达式引用触发数据），HTTP 节点推群通知。第五步试运转。拿三条测试数据走三条路径：一条两天假（主管单签）、一条五天假（会签）、一条走驳回。每条路径跑完去执行记录里核对每个节点的输入输出，三条全绿才交付。

三、结果与解读：上线两周后的账

两周后人事盘点：全部假期记录有据可查，月底对考勤从半天缩到十分钟；总监把关的长假占比与制度设计一致；年假池自动扣减，超休清零。解读这笔账的要点在「人工节点」的价值：它把流程从「全自动」的教条里解放出来——审批本质是人的判断，引擎的功劳是把判断的上下文（申请详情、余额、历史）整齐地端到审批人面前，再把判断结果可靠地接回流水线。挂起与回流是工作流里最难写对的部分，NocoBase 用一个人工节点把它做成了配置项，这是配置工种能承接审批场景的底气。

四、变式：三颗常见的加件

变式一是天数自动计算：提交后加计算节点按日期差算天数并回写，杜绝手填误差；代价是半天的调试，建议第二迭代再加。变式二是超时升级：人工节点挂起超过二十四小时未处理，自动提醒或转给上级——用定时触发器加条件节点组合实现，注意别把提醒风暴推给审批人。变式三是撤回：给申请表加「撤回」操作按钮，撤回时走一条反向流程把状态复位、通知审批人作废——多一颗螺丝，少很多电话。三个变式都仍在配置区，不需要写代码。

⚠️ 常见坑：受理人写死人名。组织架构一变，流程静默失灵——申请人提交后永远无人审批，而流程引擎不会报错，因为「等待」本身不是错误。所有人工节点的受理人一律绑关系变量，装完再做一次人事变动演练。

💡 关键直觉：审批流的装配顺序是「先归档段、后人工段」。先把通过后要做的事（写状态、扣余额、发通知）拧好，再接人工环节——因为归档段错了立刻能看见，人工环节错了要等真实审批才暴露。

深入一格：人工节点的事件轨迹

人工节点挂起期间，引擎里发生了什么值得看一遍。一次完整的审批，执行记录里会留下这样一串轨迹：

执行记录轨迹示例（五天假走会签支）：
  10:02  触发器命中：提交表单，天数=5，进入条件节点
  10:02  条件节点：天数大于三天为真，走会签支线
  10:02  人工节点·主管审批：挂起，待办推送给受理人（主管甲）
  14:35  主管甲通过：轨迹续跑，进入人工节点·总监审批
  14:35  总监审批：挂起，待办推送（总监乙）
  次日 09:10  总监乙通过：进入归档段
  09:10  增改查节点：状态写为已通过，余额扣减 5 天
  09:10  HTTP 节点：群通知推送成功，流程结束
​

这条轨迹就是流程的病历本：哪一棒快、哪一棒慢、卡在谁手里一目了然。上线两周后回看轨迹分布，你会发现瓶颈往往集中在一个环节——比如总监审批平均挂起二十小时。有了数据，优化就不是猜：给这个环节加超时提醒（3.2 变式二），或者调整受理人配置。流程优化从「感觉慢」变成「哪一棒慢、慢多少」，靠的就是把轨迹当数据看。

两个进阶问答

问一：余额扣减会不会有并发问题？两个人同时提交、同时扣同一个池子的极端场景，关系数据库的事务会保证不出现错账——引擎的写操作天然在事务里。真正的风险不在并发，在「余额不足要不要拦截」这条规则：拦截逻辑要放在流程最前端（提交校验），而不是归档段才发现扣成负数。前端挡一次，比事后追账体面得多。

问二：审批人正好是申请人怎么办？规则上应回避，实现上在人工节点的受理人逻辑里加一层条件——申请人等于主管时自动上浮一级。这颗螺丝不算常用，但一旦遇到就是尴尬事故，装流程时先想一步总没错。类似的边角还有「受理人离职」「受理人休长假」，都在同一个思路里解决：受理人永远算出来，别写死。

审批流边角自查（装配完过一遍）：
  □ 申请人即审批人的回避规则
  □ 受理人离职后的转办路径
  □ 余额不足的前置拦截
  □ 撤回或作废时挂起任务的清理
​

装配要点回顾

• 形态判定：提交、审核、归档三段式是最高频的流程形态，请假流是它的标准样板；
• 受理人绑变量：汇报关系字段驱动受理人，杜绝写死人名导致的静默失灵；
• 挂起与回流：人工节点把人的判断接进流水线，通过走归档、驳回走通知；
• 三路验收：短假、长假、驳回三条路径的执行记录全绿才算装配完成；
• 变式节奏：先跑通主流程，自动算天数、超时升级、撤回都属于第二迭代；
• 下一步：3.3 转向权限——流程跑得再顺，没有锁的应用仍是敞着门的车间。