3.1 工作流引擎：让积木自动运转
3.1 工作流引擎：让积木自动运转
本节摘要：工作流引擎由触发器、节点、执行记录三件套构成：触发器决定「何时启动」，节点决定「做什么」，执行记录保证「可回溯」。本节讲透三件套的原理与配置要点，并给出从人工习惯到自动流程的改造判断法——哪些事值得自动化，哪些自动化反而是负担。
2.4 的变式一埋了个引子：客户状态变为「成交」时自动通知主管。把「提醒主管」这件原本靠人记的事交给引擎，就是本节的主题。工作流是 NocoBase 逻辑层的核心，也是低代码平台与表格工具拉开代差的地方——表格能存数据，引擎能让数据按规矩自己动。
一、触发器：流程的扳机
触发器回答「什么时候开始」。预装触发器覆盖四类扳机：数据表事件（新增、更新、删除后触发，可按字段变化精细过滤）、定时计划（每天几点、每周几）、表单提交（用户交表即触发）、请求拦截（拦下 API 请求做校验再放行）。选扳机的判断口诀：跟着数据走用表事件，跟着日历走用定时，跟着人走用表单提交。
最常用也最容易踩坑的是数据表事件里的「更新后触发」：它对每一次保存都会触发，包括与业务无关的字段变动。精确的做法是在触发条件里限定「状态字段从某个值变为另一个值」——把扳机校准到真正的业务事件上：
// 「成交后通知主管」流程的触发器配置要点 { "type": "collection", // 数据表事件触发 "collection": "customers", "event": "update", "condition": { // 只有状态字段的变动才算数 "field": "status", "operator": "changedTo", "value": "成交" } }
二、节点：流水线上的工位
节点回答「启动之后做什么」。自动节点里高频使用的有四类：增改查节点直接读写指定数据表；计算节点做变量运算与数据拼装；条件节点按表达式分岔；HTTP 请求节点把消息推到外部。人工节点是另一大类——待办与审批——它把流程挂起，等指定的人处理完再继续。节点之间的数据传递靠上下文变量：触发那条数据、上游节点的产出，都能在下游节点的参数里引用。
一条最小可用的流程长这样（仍以成交通知为例）：
流程画布装配（工作流中心 → 新建 → 触发器选数据表事件）： 触发器：customers 更新 且 状态变为「成交」 ↓ 节点1 增改查·查询：读取当前客户的负责人用户记录 ↓ 节点2 HTTP 请求：调用企业消息接口，正文引用 「{{ 负责人姓名 }} 的客户 {{ 客户名称 }} 已成交」 启用开关：流程配置页右上角，先停用试运行、再启用
装配纪律与 2.3 的界面纪律一脉相承：一条流程只做一件事。当你在画布上画出第四个条件分岔时，停下来想一想这条流程的标题还能不能一句话说清——不能的话，拆。
三、执行记录：出问题时的行车记录仪
执行记录是引擎最容易被新手忽略的部分。每条流程的每次执行都留有记录：触发时间、每个节点的输入输出、失败原因。流程「没生效」时，先看执行记录，答案几乎总在里面——要么扳机条件没匹配上（记录列表里根本没有这条执行），要么某节点的变量引用落了空（记录里节点标红、错误信息直接可读）。
排障三步（流程不生效时）： 1. 打开该流程的执行记录列表 → 看有无本次触发的记录 无记录 → 触发器条件没匹配，回查扳机配置与数据实况 2. 有记录但中断 → 点开看中断节点，读它的输入与错误输出 3. 修正后点「重试」→ 只重放这条执行，不用重新造数据
⚠️ 常见坑：在测试环境反复触发流程往真实群里发消息。装配期用「停用」状态做画布调试，或在 HTTP 节点先指向测试地址；启用生产通知前，拿自己的账号当收件人验证一遍。
💡 关键直觉：自动化的收益 = 单次人工耗时 × 频率 − 装配与维护成本。每天三十秒的小事乘上全员乘上一年，往往就赢了；一年一次的仪式性流程，老老实实留给人做。
四、从人工习惯到自动流程的改造判断
不是所有「有点重复」的事都值得上流程。改造判断分两步：先确认动作规则是确定的（条件明确、无口头例外），再看频率与参与人数是否撑得起装配成本。两步都过，就按「扳机、节点、记录」三件套开工。规则里充满「特殊情况特殊处理」的，先做规则梳理，或者把例外部分留给人工节点——引擎擅长的是确定性，不是读心术。
嵌套深度是另一条经验红线：条件套条件超过三层，流程的可读性断崖式下跌。三层以内的分岔留在画布上，更深的规则拆成多条流程接力，或者提示开发者做自定义节点（第 4 章正是为此准备的）。流程画布是给「人能看懂」用的，不是给「机器能执行」用的——机器不在乎，你的继任者在乎。
流程改造的两道争议题
争议一：流程该一条长的还是多条短的？画布支持把一条流程编得很长，但长流程的维护成本呈几何级数上涨——改一个中间节点，下游全要回归。现场答案：按「业务事件」切分，一个事件一条流程，事件之间用数据状态衔接。状态字段在这里兼任了流程之间的接力棒：这条流程把状态写到某值，那条流程监听该值接管下一程。流程短了，执行记录好读，责任好认，出问题按状态字段一查便知断在哪一棒。
争议二：自动化之后人干什么？合理的答案是把人放到流程的例外位而不是执行位。以成交通知为例，自动化覆盖的是「通知」这个确定性动作，人保留的是「判断通知之后跟不跟进」。如果一条流程把人完全挤出去，先别庆祝效率提升，检查一下异常路径谁来兜——好的自动化都长着一条清晰的人工兜底支线，这条支线在图上可能只是条件分支后面的一个待办节点，平时安静，出事时就是安全网。
流程改造验收三问（启用前自查）： 1. 扳机是否校准到业务事件？（无关保存不触发） 2. 异常路径有人兜底吗？（失败通知或人工节点） 3. 执行记录的留痕够复盘吗？（节点输入输出可见）
装配要点回顾
- 三件套：触发器管何时、节点管做什么、执行记录管可回溯，认识流程先认这三样；
- 扳机校准：更新事件必须限定字段变化条件，否则无关保存也会放响枪；
- 变量传递：上下文变量让触发数据与上游产出在节点间流转，是流程的血液；
- 排障入口：执行记录是行车记录仪，「没生效」先看它，再看扳机，最后才看节点；
- 改造判断：确定性规则加足够频率才值得自动化，三层嵌套是画布的红线；
- 下一步：3.2 把这套三件套拧进一桩完整的审批实战——请假流程装配记。