上一篇写权限体系，最后说到一个判断：
权限解决的是边界，流程解决的是业务如何往前走。
这一篇就接着写流程引擎。
流程这个模块，很多人第一反应是审批流。
请假审批、报销审批、合同审批、采购审批。画几个节点，配置审批人，再加几个条件分支，好像流程引擎就完成了。
我最开始也容易这么想。
但真正做低代码平台以后，会发现流程引擎远不止“画审批流”。
它要解决的是：一条业务数据从创建、提交、审核、退回、修改、完成，到后续触发自动化和数据变化，整个过程能不能被平台稳定地描述、执行和追踪。
换句话说，流程引擎不是一个独立功能，而是业务运行时的一部分。
流程不是图，而是状态变化
流程设计器里最显眼的是图。
开始节点、审批节点、条件分支、抄送节点、结束节点。
织信工作流设计器里的典型流程
这些图形很重要，因为用户需要用它理解业务路径。
但对系统来说，真正重要的不是图，而是状态变化。
一张合同从草稿变成审批中，再变成法务审核、财务审核、已通过、已驳回、已归档，这些状态变化才是业务真正发生的事情。
如果流程只停留在图上，就会出现一个问题：
图画得很漂亮，但数据状态、权限、通知、日志和后续自动化都没有被真正串起来。
所以我更愿意把流程理解成一套状态机。
节点是状态。
连线是状态变化路径。
审批动作是状态变化的触发条件。
流程记录是状态变化的历史。
这样设计以后，流程就不只是“谁审批”，而是“业务对象在什么条件下进入什么状态”。
流程必须绑定业务对象
低代码平台里的流程，不能脱离数据模型单独存在。
如果流程只是一个空的审批模板，它很难真正进入业务。
流程必须绑定具体业务对象。
比如合同审批，绑定的是合同表。
费用报销，绑定的是报销单表。
采购申请，绑定的是采购申请表。
项目立项，绑定的是项目表。
绑定以后，流程才能读到业务字段。
合同金额是多少？
客户等级是什么？
申请部门是谁？
项目预算是多少？
是否涉及外部供应商？
这些字段会决定流程怎么走。
比如合同金额小于十万，只需要部门负责人审批；超过十万，还要财务审核；涉及特殊条款，还要法务审核。
这说明流程不是凭空运行的，它依赖数据模型。
数据模型越清楚，流程表达就越稳定。
审批人不是固定写死的
做流程时，一个很容易被低估的问题是审批人。
简单场景里，可以直接指定某个人审批。
但企业真实流程很少这么简单。
审批人可能是发起人的直属上级。
可能是发起人所在部门负责人。
可能是某个角色，比如财务、法务、采购负责人。
可能来自表单字段，比如项目负责人、客户负责人、合同归属人。
也可能根据金额、地区、业务线动态变化。
如果审批人只能写死，流程很快会失去弹性。
所以流程引擎必须支持动态审批人。
这里会牵涉组织架构、角色、用户字段、部门字段和规则表达式。
也就是说，流程引擎会天然依赖权限体系和组织模型。
这也是为什么我不太赞成把流程做成一个孤立模块。
它看起来是在处理审批，实际上是在调度企业组织里的责任关系。
条件分支最怕变成黑盒
流程里的条件分支也很关键。
条件分支看起来只是一个判断：
金额大于十万走财务。
客户等级为 A 走高级审批。
申请部门为研发走技术负责人。
字段为空时退回补充。
这些规则如果少，问题不大。
但规则一多，就容易变成黑盒。
用户会问：
为什么这张单走了法务？
为什么没有走财务？
为什么我的申请被退回？
为什么同样金额的合同走了不同路径？
如果系统只能回答“流程配置就是这样”，其实是不够的。
我觉得流程引擎至少要留下可解释的执行记录。
哪一个分支被命中。
判断时读取了哪些字段。
当时字段值是什么。
哪个条件成立，哪个条件不成立。
这类信息对排查问题非常重要。
否则流程出了问题，最后只能靠开发查日志，业务人员自己看不懂。
退回不是简单回到上一步
很多流程引擎里都有“驳回”或“退回”。
但退回其实很复杂。
退回到发起人？
退回到上一个节点？
退回到指定节点？
退回后重新提交，是从头开始，还是从退回节点继续？
退回期间哪些字段可以修改？
退回记录是否保留？
之前审批人的意见是否还有效？
比如合同审批中，法务退回让销售补充条款。销售修改后，是不是还要重新走部门负责人？财务之前的审核还算不算？
这些问题没有统一答案，要看业务。
所以流程引擎不能把退回做成一个固定动作。
它应该成为一种可配置的流转方式。
退回到哪里、是否重走、哪些字段开放修改、原审批意见怎么处理，都要进入流程设计。
流程会改变权限
上一篇写权限时提到过，流程和权限不能分开看。
现在换到流程角度，这个问题会更明显。
同一张报销单，在不同流程状态下，权限是不一样的。
草稿状态，发起人可以编辑。
提交后，发起人不能再改金额。
部门负责人审批时，可以填写审批意见。
财务审核时，可以修改费用科目。
流程结束后，普通人只能查看。
这说明流程节点会改变字段权限和动作权限。
如果流程引擎不和权限体系打通，就只能靠前端页面临时控制。
这样很危险。
因为用户可能通过接口、导入、自动化或 AI 绕过前端限制。
所以流程节点上的权限，必须成为平台后端判权的一部分。
流程走到哪里，权限就应该跟着变化。
流程不只是审批，还包括自动动作
企业流程里，不是每一步都需要人处理。
很多节点应该自动完成。
合同审批通过后，自动生成合同编号。
采购申请通过后，自动创建采购单。
项目立项通过后，自动创建任务模板。
客户阶段变成已成交后，自动通知实施团队。
报销通过后，自动写入付款计划。
这些动作如果都让人手工处理，流程只是把责任从一个人推给另一个人，没有真正减少工作量。
所以流程引擎必须支持自动节点。
自动节点可以执行字段更新、状态变更、通知、创建记录、调用接口、执行脚本、触发自动化。
这会让流程从“审批工具”变成“业务编排工具”。
我觉得这是低代码平台和普通审批系统的一个重要区别。
流程记录比流程图更重要
流程图描述的是设计。
流程记录描述的是事实。
企业真正追责和复盘时，看的是事实。
谁在什么时间提交。
谁审批通过。
谁退回。
退回原因是什么。
哪个条件分支被命中。
系统自动执行了什么动作。
接口调用是否成功。
流程耗时多久。
某个节点卡了多长时间。
这些信息不只是日志，也是业务数据的一部分。
如果流程记录不完整，后面做统计、审计、AI 分析都会很困难。
比如管理者想知道合同审批平均耗时，不能只看当前合同状态，而要看每个节点的开始时间和完成时间。
再比如 AI 想总结“本周审批卡点”，也要依赖流程记录。
所以流程引擎一开始就要把执行记录设计好。
后补会很痛苦。
第一版流程引擎我会怎么取舍
流程引擎很容易做大。
BPMN、会签、或签、加签、转交、撤回、退回、子流程、定时器、消息事件、异常边界、补偿机制……
这些能力都重要，但第一版不能一口吃完。
如果让我做第一版，我会先保证几件事。
第一，流程必须绑定数据表。
流程不能是孤立模板，必须围绕业务对象运行。
第二，节点类型先控制住。
开始、人工审批、条件分支、自动动作、结束，先把主链路跑通。
第三，审批人要支持动态配置。
至少要支持指定成员、角色、部门负责人、字段人员和发起人上级。
第四，流程状态要写回业务数据。
业务记录要能知道自己处在草稿、审批中、已通过、已驳回、已撤回等状态。
第五，节点权限要进入后端判权。
哪些字段可见、可编辑，哪些动作可执行，不能只靠前端。
第六，流程记录要完整。
每一次提交、审批、退回、自动执行，都要留下结构化记录。
第七，自动节点要先支持最常见动作。
字段更新、创建记录、发送通知、调用接口，这几类动作最实用。
这些能力做稳以后，再逐步加会签、加签、子流程和更复杂的事件机制。
做流程时最容易踩的坑
第一个坑，是只关注流程图。
图画出来不代表流程真的能跑。状态、权限、记录、异常处理都要跟上。
第二个坑，是审批人写死。
一开始简单，后面组织变化、人员调整、跨部门流程一多，就会非常难维护。
第三个坑，是退回逻辑太粗。
退回不是“回到上一步”这么简单，它会影响数据修改、审批意见和后续路径。
第四个坑，是流程和权限分离。
节点权限如果不进入判权体系，流程状态就很容易被绕过。
第五个坑，是自动动作没有记录。
系统自动改了字段、创建了记录、调用了接口，如果没有日志，出了问题很难查。
第六个坑，是一开始就做得太复杂。
流程引擎当然可以很复杂，但低代码平台第一版更需要稳定、可解释、可扩展。
先让常见企业流程跑稳，比追求所有高级能力更重要。
写在最后
流程引擎是低代码平台里非常容易被误解的模块。
它表面上是画流程、配审批人。
但往深了看，它连接了数据模型、权限体系、组织架构、自动化、集成和审计。
数据模型告诉流程处理的是什么对象。
权限体系决定每个节点能看什么、能改什么。
组织架构决定责任应该交给谁。
自动化让流程不只是人工传递。
集成让流程可以连接外部系统。
流程记录让业务过程可以追踪和复盘。
所以流程引擎不是一个审批插件。
它是企业业务运行的轨道。
对织信来说，流程引擎要解决的不是“能不能画出一张审批图”，而是业务对象能不能沿着清晰、可控、可追踪的路径往前走。
