经典模式、仿钉钉模式共用节点属性面板。进入审批节点的“办理人设置”，点击“选择办理人”，切换到“动态规则”页签，勾选需要的规则并确定。节点表格和画布回显规则名称，保存并重新打开后保留配置。
| 规则 | 实际存储的Warm-Flow表达式 | 后端处理 |
|---|---|---|
| 申请人 | ${wfApplicant} |
本次发起流程的已登录用户 |
| 本部门副主管（无则主管） | ${wfDepartmentApprovers} |
查申请人所在部门的有效副主管；排除本人、无效账号后没有候选人时，查本部门主管 |
| 上一级部门主管 | ${wfParentDepartmentApprovers} |
查申请人所在部门的直接上级部门主管，不是上一位审批人的上级 |
多个副主管任意一人通过，应在节点“基础设置”中选择“或签”。候选人规则只负责选人，不会强行覆盖设计器设置的会签、票签等协作方式。
固定角色、部门、用户仍按原方式选择；同一节点可选择多个办理项，表达式按引擎机制展开后合并。手动输入合法标识、离开输入框时回显名称；不认识的自定义变量不会在表格中被自动删除，但宿主必须自行提供变量，未解析的表达式不能生成有效任务。
flow-api 定义动态规则模型和 WorkflowDataProvider 基础数据查询端口；flow-core 实现 WorkflowIdentityProvider，负责规则解析、候选人展开及展示名称组装，不依赖 upm-core。infra-start 的 UpmWorkflowDataProvider 只使用 UPM Service 查询用户、部门和主管任职等基础数据。独立宿主只需用本地 Service、Feign 或 Dubbo 实现 WorkflowDataProvider，不必复制动态规则和目录组装逻辑。
WorkflowAssigneeResolver 在启动前读取当前租户已发布定义，按需要解析规则，将用户ID列表写入实例变量；Warm-Flow原生 ${变量名} 机制解析为任务办理人。沿用现有权限适配和候选人校验，不另建审批引擎，也不要求用户填写监听器。
三个 wf... 变量为服务端保留变量，发起、通过和退回时，业务调用方不得覆盖。当前HTTP办理接口也不接受客户端修改流程变量。未解析的表达式和空候选人会导致事务回滚，不留下无人可办的任务。
本轮使用发起时的审批人快照：后续审批、退回再办理使用同一实例保存的变量，不根据当前审批人的部门重新选人，也不因组织调整自动换人。账号在后续流转时失效则由原有有效账号校验拒绝流转，应由管理员按实际业务处理，不自动找其他人替代。
实例只读图展示规则名称；当前任务和历史中的用户姓名展示仍属于独立的后续需求。
leave 定义创建新版本，不修改已产生实例的旧版本。不需要增加数据库表、字段或执行SQL；内置规则作为既有节点 permissionFlag 保存，快照使用既有实例变量。
请假示例已支持“申请人提交”普通办理节点：该节点只配置“申请人”规则，作为开始后的唯一首个任务；首次业务提交自动完成，退回到该节点后可修改表单并在原实例重新提交。无需申请人审核自己，也不允许用通用审批按钮绕过表单校验。定义中的申请节点必须唯一，不按名称识别，不能与其他任务并行；配置、接口与权限说明见请假申请示例。其他业务应自行适配申请任务识别与业务表单提交，不能只添加表达式就自动获得表单修改能力。
引擎集成测试覆盖“申请人提交→本部门多人或签→上级部门主管→结束”，以及退回申请人后重新办理、保留原申请人审批配置、阻止覆盖保留变量、无有效候选人时不创建实例。UPM适配测试覆盖副主管优先、主管兜底、本人排除、停用账号过滤和跨租户部门拒绝。前端组件测试覆盖动态页签选择、表达式手填回显、经典及仿钉钉模式的保存与重新打开。