审批流程上线后改规则，进行中的单据该走旧流程还是新流程

审批规则改变后，在途单据走哪版不能由“保存配置”顺带决定。建议先写清新规则对哪些新单生效，再按单据当前节点选择继续旧版、显式迁移或撤回重提。每种选择都应保留原审批依据和处理记录。这里讨论运行中的单据，与项目需求变更及源码交接属于不同范围。

流程定义、单据实例和人员规则要分开

流程定义描述审批步骤和分支，一张已提交的单据则是某版流程的实例。人员规则可能另行决定“部门负责人”当前是谁。建议记录实例所用流程版本、关键条件值及人员解析方式：按提交时人员固定，还是进入节点时重新计算，应明确选择。

Camunda 的版本管理文档说明该产品默认让在途实例继续原定义，新实例采用最新定义。这证明发布与迁移可以分开管理，不意味着采购的任意审批系统都会如此。评估软件开发方案时，应要求用实际产品版本演示这一区别。

给在途单据选择一条明确路径

业务负责人应确认制度生效时间、适用组织、单据类型和例外范围。不要只写“从今天开始”，而要说明以首次提交、重新提交还是进入某个节点为界。以下三种路径各有代价，可按受影响状态组合使用。

不建议删除原单再创建一张无关联的新单。已批准、已付款或已通知外部系统的动作，应按实际业务另行处理，改变流程图不能被视为这些动作已经撤销。

把退回和代理情形放进版本边界

假设审批单在新规则生效前提交，生效后被退回修改。只修正附件是否保留原版，改动金额或部门是否需按新版重新审批，应逐项约定；这里没有可直接套用的统一答案。页面应说明当前生效规则及重新提交的影响。

负责人离职也不必自动改整个流程。可在被授权的代理或转交规则内继续办理，但需要区分原指定人、实际处理人和操作依据。如果新版本新增一道审核，已越过该位置的单据是否补审，需要业务确认，不能假定迁移后会自动补齐历史步骤。

迁移前先核对活动节点和输入条件

建议先按版本、当前节点、并行分支和异常状态列出在途实例清单，再选择代表性样本演练。Camunda 实例迁移文档要求提供节点映射，并说明活动节点及既有作业等状态存在限制。具体实现应检查所用引擎能力，不能把图上名称相同当成可安全迁移。

迁移清单至少写明源节点、目标节点、需要补充的变量、待办归属和后续路由。操作期间如何处理同时到达的审批提交，也应约定暂停或冲突机制。完成后逐项核对待办和历史记录，而不是只确认管理员界面显示成功。

用实际在途状态验收，并约定回退边界

1. 生效前后各提交一张单据，核对实际流程版本与分支。
2. 对已到中间节点、退回待修改和并行会签中的单据分别演练，不只测试新建单。
3. 更换负责人或设置代理，核对旧待办去向和办理身份记录。
4. 让迁移与审批操作相遇，确认单据不会重复流转、跳步或丢失意见。

若新版有问题，恢复旧定义只能改变约定范围内的后续行为，不能自动撤销已发生的审批。应保存受影响实例清单，明确哪些能回到原路径、哪些需要补偿或人工复核。将这些条件写进需求与验收条目，交付时核对版本、单据和操作证据三者对应。