操作：批量发起审批

在订单、合同、费用、采购、报销等业务中，审批通常是“一条业务数据对应一条审批流程”。没有批量操作时，业务人员需要逐条打开数据、点击发起审批，既耗时，也容易漏发或重复发起。

操作：批量发起审批在表格中增加一个批量操作。用户选中多条业务数据后，只需点击一次，插件就会为每条数据独立发起对应的审批工作流。

它带来的直接效果：

业务痛点	使用插件后的效果
大批量单据需要逐条发起审批，操作重复	一次选择多条数据，批量触发独立审批，单次最多 50 条
重复点击可能造成同一单据重复提交	发起前检查审批状态，已提交、审批中、已通过的数据自动跳过
退回、拒绝、失败等历史状态处理不一致	可按业务规则分别决定是否允许再次提交或重新申请
批量操作结束后不知道哪些成功、哪些未处理	结果页显示已发起、跳过、失败的数量和逐条原因

插件只负责发起审批，不会替审批人完成审批，也不会修改业务数据本身。每条记录仍然使用原有审批工作流、审批节点和权限规则。

使用后的流程

业务人员的实际操作如下：

1. 在多记录表格中勾选 1–50 条记录。
2. 点击 批量发起审批，确认本次使用的审批工作流和记录数量。
3. 点击 发起审批。系统逐条检查记录并提交符合条件的数据。
4. 查看汇总结果。已成功发起的记录会从当前选择中移除；跳过或失败的记录会保留，方便继续处理。

适用范围与前提

支持范围

• 操作只支持绑定与当前数据表匹配且已启用的审批工作流。
• 单次最多选择 50 条数据；每条数据独立发起，不会合并成一条审批。

暂不支持

• 不支持单记录区块、详情区块或非表格数据区块。
• 不会自动修改业务记录字段，也不会自动完成后续审批节点。

使用前提

• 已安装并启用工作流插件和审批插件。
• 已在目标业务数据表上创建审批工作流，并确保工作流处于“启用”状态。
• 当前用户对目标数据表有读取权限。

配置步骤

第一步：准备审批工作流

先在目标业务数据表上配置常规审批工作流。工作流需要满足以下条件，才会出现在批量操作的选择列表中：

• 类型为审批工作流；
• 已启用；
• 绑定当前操作所在的数据表；

工作流中的审批节点、审批人、抄送人和触发条件仍按审批插件的原有方式配置。

第二步：在表格操作区添加批量操作

1. 打开目标页面，进入设计模式。
2. 在目标表格上方的操作区添加 批量发起审批。

第三步：配置审批发起设置

在操作设置中打开 审批发起设置，按实际业务规则填写以下内容。

配置项	是否必填	说明
工作流	必填	选择当前数据表对应的已启用审批工作流。下拉列表不会展示其他数据表的工作流。
跳过/失败记录显示字段	选填	结果页中用于识别跳过或失败记录的业务字段，例如订单号、合同编号。字段必须已加载到当前表格；未加载、为空或取不到值时回退显示记录主键（通常是 ID）。
退回后允许再次提交	选填	开启后，被退回记录可由原申请人再次提交；系统会继续使用原审批申请，不会创建新的审批记录。
拒绝后允许重新申请	选填	开启后，被拒绝记录可以重新发起一条新的审批申请。
工作流执行失败后允许重新申请	高级设置	仅在确认故障已排除后开启。开启后，工作流执行失败的记录可以再次发起。
审批终止后允许重新申请	高级设置	开启后，已终止的审批可以重新发起；建议先确认终止原因允许再次申请。

所有“允许再次提交/重新申请”的开关默认关闭。关闭时，对应历史状态会被安全跳过，不会产生新的审批。

运行时规则

每条记录都会单独校验

点击发起后，系统不会把选中的记录拼成一个“大审批”。每条记录都独立调用审批服务，并依次检查：

1. 当前用户是否有权读取该记录；
2. 当前记录是否存在历史审批或进行中的审批；
3. 当前记录是否满足工作流的触发条件。

因此，同一批数据可以同时出现“已发起”“已跳过”和“失败”，这是按记录分别校验后的正常结果。

审批状态处理

当前状态	默认行为	开启对应设置后的行为
无历史审批	发起新审批	发起新审批
已提交	跳过，防止重复提交	仍跳过
审批中	跳过，防止重复发起	仍跳过
已通过	跳过，保留审批结果	仍跳过
已退回	跳过	开启“退回后允许再次提交”且当前用户是原申请人时，重新提交原审批
已拒绝	跳过	开启“拒绝后允许重新申请”后，新建审批申请
工作流执行失败	跳过	开启“工作流执行失败后允许重新申请”后，新建审批申请
审批已终止	跳过	开启“审批终止后允许重新申请”后，新建审批申请
状态无法确认	跳过	仍跳过，以避免不确定的重复提交

进度与结果

• 界面会显示已完成数量和进度条。
• 某一条记录失败不会中断其他记录；系统会继续处理本批次剩余记录。
• 请求失败不会自动重试，避免网络抖动或服务端不确定时造成重复发起。
• 结果页会显示总数、已发起数、跳过数和失败数，并列出跳过/失败原因。
• 已发起成功的记录会移出当前选择；跳过或失败的记录会保留。

常见结果与处理建议

结果提示	常见原因	建议
已跳过：已有进行中的审批	记录已提交或正在审批	无需重复操作，直接进入审批处理或查看待办
已跳过：审批已退回	未开启退回后再次提交，或当前用户不是原申请人	按业务规则开启开关，或交由原申请人处理
已跳过：审批已拒绝/已终止/工作流失败	对应开关关闭	确认业务是否允许重新申请；允许时开启对应设置后再次执行
失败：不满足工作流触发条件	当前记录不符合审批工作流条件	检查记录字段和工作流条件，修正数据后再发起
失败：记录不存在或无权访问	数据已删除、当前角色没有读取权限	检查数据是否仍存在以及角色的数据表读取权限
失败：审批工作流不可用	工作流被停用、版本变化或不再绑定当前数据表	重新检查工作流配置，并在操作设置中重新选择可用工作流
结果中只显示 ID	显示字段未加载、为空或无法从当前行读取	将目标字段加入表格或重新配置“跳过/失败记录显示字段”

典型应用场景

批量提交待审订单

销售或订单专员筛选出当天需要审核的订单，批量发起“订单审批”。已提交或已通过的订单自动跳过，避免重复触发；结果页可用订单号快速定位异常记录。

批量提交费用或报销单

财务人员在完成初审后，选择多条费用单据一次提交。对于被退回的单据，可允许原申请人重新提交；对于被拒绝的单据，则按制度决定是否开放重新申请。

批量推进合同或采购审批

业务人员在完成批量录入后统一发起审批，减少逐条打开详情页的时间。工作流仍按每份合同或采购单独执行，审批人看到的待办互不混淆。

安全与数据边界

• 发起人身份取自当前登录用户和当前角色，不能通过页面参数伪造。
• 服务端会再次校验数据表读取权限、数据范围，不只依赖前端选择结果。
• 插件只提交审批请求，不会替用户修改业务记录，也不会改变审批工作流本身。
• 已存在的审批历史会被保留；“退回后再次提交”复用原审批申请，“拒绝后重新申请”等情况才会创建新的申请。