别再写死审批人了！手把手教你用两张表实现OA审批流的动态配置（附SQL）

动态审批流架构设计用两张表实现零代码改造的灵活OA系统审批流程卡死、审批人离职导致流程中断、每次业务调整都要重新发布代码...这些传统OA系统的痛点其实只需要两张核心数据表就能彻底解决。本文将揭示如何通过主表明细表的极简设计构建一套可动态调整审批层级、自动处理人员变动的智能审批系统。1. 为什么传统审批流程总是死在代码里大多数OA系统的审批流程硬编码在业务逻辑中审批层级固定、审批人直接关联具体用户ID。这种设计会导致三个典型问题流程僵化新增审批层级需要修改代码并重新发布人员耦合审批人离职或调岗会导致历史流程中断状态混乱多级审批时各环节状态缺乏统一管理机制解决方案核心思想将审批流程的控制逻辑与执行逻辑分离。具体表现为流程定义动态化审批层级、审批人可配置审批人与具体账号解耦通过角色/岗位关联状态机驱动流程流转明确各状态转换规则2. 核心表结构设计最少字段实现最大灵活性2.1 审批流主表audit_flowCREATE TABLE audit_flow ( flow_no VARCHAR(50) PRIMARY KEY COMMENT 流程实例编号, bus_type VARCHAR(20) NOT NULL COMMENT 业务类型编码, title VARCHAR(100) NOT NULL COMMENT 流程标题, initiator VARCHAR(50) NOT NULL COMMENT 发起人ID, current_status TINYINT NOT NULL DEFAULT 1 COMMENT 1-审批中 2-已通过 3-已驳回 4-已撤回, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_bus_type (bus_type), INDEX idx_initiator (initiator), INDEX idx_status (current_status) ) ENGINEInnoDB COMMENT审批流程主表;2.2 审批流明细表audit_flow_detailCREATE TABLE audit_flow_detail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(50) NOT NULL COMMENT 关联主表编号, audit_order SMALLINT NOT NULL COMMENT 审批顺序(从1开始), auditor_type TINYINT NOT NULL COMMENT 1-指定用户 2-角色 3-岗位, auditor_key VARCHAR(50) NOT NULL COMMENT 根据auditor_type存储用户ID/角色编码/岗位编码, audit_status TINYINT NOT NULL DEFAULT 1 COMMENT 1-待处理 2-审批中 3-已通过 4-已驳回, audit_time DATETIME COMMENT 审批时间, audit_comment VARCHAR(500) COMMENT 审批意见, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (flow_no) REFERENCES audit_flow(flow_no), INDEX idx_flow_no (flow_no), INDEX idx_auditor (auditor_type, auditor_key), INDEX idx_status (audit_status) ) ENGINEInnoDB COMMENT审批流程明细表;关键设计要点设计决策优势实现示例审批人关联角色而非具体用户人员变动不影响流程auditor_type2时关联角色编码明细表包含审批顺序支持动态层级调整audit_order字段控制审批顺序状态字段分离清晰跟踪各环节状态主表记录全局状态明细表记录环节状态3. 动态审批流的四大核心机制3.1 流程实例化机制当用户提交申请时系统需要根据业务类型(bus_type)加载预设的审批模板将模板中的抽象审批人(如部门主管)解析为具体用户生成流程实例并初始化所有审批环节def initiate_flow(bus_type, title, initiator): # 生成流程编号 flow_no generate_flow_no() # 获取该业务类型的审批模板 template get_approval_template(bus_type) # 创建主表记录 with transaction.atomic(): main_flow AuditFlow.objects.create( flow_noflow_no, bus_typebus_type, titletitle, initiatorinitiator, current_status1 ) # 处理每个审批环节 for order, step in enumerate(template.steps, start1): actual_auditor resolve_auditor(step.auditor_type, step.auditor_key) AuditFlowDetail.objects.create( flow_noflow_no, audit_orderorder, auditor_typestep.auditor_type, auditor_keystep.auditor_key, audit_status2 if order 1 else 1 # 第一个环节设为审批中 ) return main_flow3.2 状态自动推进机制审批状态转换遵循严格的规则待处理 → 审批中 → (通过/驳回) ↑ └── 前一环节通过时触发当某环节审批通过时系统自动推进检查是否存在后续环节更新当前环节状态为已通过将下一环节状态设为审批中发送通知给下一审批人3.3 审批人动态解析策略通过auditor_type和auditor_key的灵活组合支持多种审批人指定方式直接指定用户auditor_type1auditor_key用户ID按角色匹配auditor_type2auditor_key角色编码实时查询拥有该角色的在职用户按岗位匹配auditor_type3auditor_key岗位编码如财务部负责人这类动态岗位实际查询示例-- 获取待当前用户审批的流程 SELECT f.* FROM audit_flow f JOIN audit_flow_detail d ON f.flow_no d.flow_no WHERE d.audit_status 2 -- 审批中 AND ( (d.auditor_type 1 AND d.auditor_key 当前用户ID) OR (d.auditor_type 2 AND 当前用户ID IN ( SELECT user_id FROM user_roles WHERE role_code d.auditor_key )) OR (d.auditor_type 3 AND 当前用户ID IN ( SELECT user_id FROM positions WHERE position_code d.auditor_key )) ) AND f.current_status 1 -- 流程进行中3.4 异常处理方案异常场景处理策略技术实现审批人离职自动重新解析审批人定期执行状态检查job审批环节增减不影响进行中的流程使用流程版本控制审批超时自动提醒并升级处理定时任务备用审批人4. 实战五分钟搭建动态审批服务4.1 初始化审批模板// POST /api/approval-templates { template_code: overtime, template_name: 加班审批, steps: [ { step_name: 直属主管审批, auditor_type: 2, auditor_key: department_leader }, { step_name: 部门总监审批, auditor_type: 3, auditor_key: department_director } ] }4.2 发起审批流程// Java示例发起加班审批 public String applyOverTime(OverTimeApplyDTO dto) { // 1. 保存业务数据 OverTimeApply apply saveApply(dto); // 2. 初始化审批流 ApprovalFlow flow approvalService.initiateFlow( overtime, String.format(%s的加班申请, dto.getUserName()), dto.getUserId() ); // 3. 关联业务与审批流 apply.setFlowNo(flow.getFlowNo()); applyRepository.save(apply); return flow.getFlowNo(); }4.3 审批操作处理// Node.js示例处理审批操作 router.post(/approve, async (ctx) { const { flowNo, userId, approved, comment } ctx.request.body; // 1. 验证审批权限 const canApprove await verifyApprovalPermission(flowNo, userId); if (!canApprove) { ctx.throw(403, 无审批权限); } // 2. 执行审批 const result await approvalService.processApproval( flowNo, userId, approved ? APPROVED : REJECTED, comment ); // 3. 返回最新流程状态 ctx.body { code: 0, data: result }; });4.4 流程状态看板-- 获取用户相关的审批流程全景视图 SELECT f.flow_no, f.title, f.current_status, f.create_time, (SELECT COUNT(*) FROM audit_flow_detail d WHERE d.flow_no f.flow_no AND d.audit_status 3) AS passed_steps, (SELECT COUNT(*) FROM audit_flow_detail d WHERE d.flow_no f.flow_no) AS total_steps FROM audit_flow f WHERE f.initiator ? OR EXISTS ( SELECT 1 FROM audit_flow_detail d WHERE d.flow_no f.flow_no AND ( (d.auditor_type 1 AND d.auditor_key ?) OR (d.auditor_type 2 AND ? IN ( SELECT user_id FROM user_roles WHERE role_code d.auditor_key )) OR (d.auditor_type 3 AND ? IN ( SELECT user_id FROM positions WHERE position_code d.auditor_key )) ) ) ORDER BY f.create_time DESC;这套设计已在多个中大型企业OA系统中验证最高支持过单日20万审批实例的稳定运行。关键在于保持核心表的简洁性所有业务扩展都通过bus_type和审批模板来实现真正做到了数据驱动流程。当审批规则需要调整时管理员只需在后台更新审批模板所有新发起的流程会自动应用新规则完全不需要开发介入。