Flowable 工作流超时提醒、超时预警与超时自动审批

Flowable 中的“任务到期时间”与“定时器”不是同一件事。任务 dueDate 适合展示截止时间、筛选即将超时和统计 SLA，但它不会因为时间到了就自动发送消息或完成任务；真正负责按时触发动作的是 BPMN 定时器事件及其运行时作业。

超时提醒通常使用非中断边界定时器，定时器触发后发送站内信、短信、邮件或企业微信，但原审批任务继续等待。超时预警是在正式截止时间之前触发，可以提醒办理人、部门负责人或流程管理员。超时自动审批则应使用中断边界定时器进入一条明确的自动处理支线，由规则判断是自动通过、自动驳回、转人工还是终止，不能把“超时”简单等同于“同意”。

截至 2026 年 8 月，Flowable 最新开源版本为 8.0.0。官方 BPMN 文档支持 timeDate、timeDuration、timeCycle 和业务日历；异步执行器把定时器保存为运行时作业，到期后通过数据库锁获取并执行。这套机制能够支撑企业审批 SLA，但前提是把时间口径、幂等、重复提醒、并行与会签边界设计清楚。

一、核心结论与问题边界

一句话回答：提醒不打断，预警早触发，自动审批必须经过规则

三类能力可以用一条时间线区分：

能力	触发时间	是否取消当前任务	推荐动作
超时预警	截止时间之前	否	提醒办理人、负责人或管理员
超时提醒	到期时或到期后周期触发	否	多渠道催办、升级提醒、记录次数
超时自动审批	到期或宽限期结束	通常是	进入规则决策，自动通过、驳回、转办或人工兜底

“预警”和“提醒”主要改变通知状态，不应改变审批结论；“自动审批”会改变流程路径和业务状态，必须拥有独立的权限、审计、规则版本和例外处理机制。

任务 dueDate 与 BPMN 定时器有什么区别

Flowable 用户任务可以配置到期时间。官方文档说明，到期时间可以是日期、ISO 8601 字符串、持续时间或表达式；任务查询 API也支持查询指定日期之前、之后或没有到期时间的任务。它适合待办列表显示“还剩 2 小时”、预警看板和批量统计。

但是 dueDate 只是任务字段。把它改成昨天，并不会自动创建消息，也不会自动完成任务。若企业用定时扫描任务表实现催办，需要自己处理扫描频率、重复发送、任务已完成但扫描结果过期等问题。

BPMN 定时器是流程执行语义。流程进入带有边界定时器的用户任务时，Flowable 会创建定时器作业并保存触发时间。到期后，异步执行器获取作业并沿定时器出口继续流程。它适合需要可靠驱动流程路径的提醒、升级和自动处置。

因此推荐“双轨设计”：任务 dueDate 作为可查询的 SLA 截止时间，BPMN 定时器作为可靠执行机制。两者可以来自同一个 SLA 计算结果，但不能假设修改其中一个会自动同步另一个。

二、关键概念与能力差异

Flowable 定时器有哪些时间表达方式

Flowable 的定时器定义必须选择一种时间表达：

• timeDate：固定时间点，例如 2026 年 8 月 8 日 18:00，适合已经算好的预警时间或截止时间。
• timeDuration：从定时器创建开始计算的持续时间，例如 PT30M、P2D，适合“进入节点后两小时提醒”。
• timeCycle：周期触发，例如 R3/PT2H 表示每两小时一次、最多三次，适合重复催办。
• Cron：适合周期性启动流程或固定时间窗口，但应注意 Flowable Cron 的第一位是秒，不是传统 Unix Cron 的分钟。

企业审批经常需要工作日、节假日和工作时段。Flowable 允许定时器指定业务日历；企业可以把“两个工作日”“下一个工作日上午 9 点”转换成准确触发时间。业务日历不是简单跳过周末，还要明确法定节假日、调休、地区、租户和跨时区规则。

超时提醒怎么建模

超时提醒最常见的做法，是在用户任务上挂一个 cancelActivity="false" 的非中断边界定时器。定时器触发后沿提醒支线发送通知，原用户任务仍然存在，办理人可以继续审批。

下面是一个重复三次、每两小时提醒一次的核心 BPMN 片段：

<userTask id="managerApproval"
          name="部门经理审批"
          flowable:dueDate="${approvalDueDate}" />

<boundaryEvent id="reminderTimer"
               attachedToRef="managerApproval"
               cancelActivity="false">
  <timerEventDefinition>
    <timeCycle>R3/PT2H</timeCycle>
  </timerEventDefinition>
</boundaryEvent>

<sequenceFlow sourceRef="reminderTimer" targetRef="sendReminder" />
<serviceTask id="sendReminder" name="发送催办通知" />

非中断定时器每次触发都会生成一条并行执行支线。发送通知后，这条支线应明确结束，不能重新回到原任务，否则容易形成额外令牌或重复路径。边界事件不要直接配置多条出口；官方文档提示并发场景下应先连接一个出口，再通过并行网关拆分邮件、短信等动作。

提醒次数、最后提醒时间和渠道发送结果建议放在业务通知记录中，而不是不断向流程变量追加大对象。每次发送使用“流程实例 + 任务 + 提醒级别 + 计划触发时间”组成幂等键，避免作业重试或消息重复投递造成多次通知。

三、模型架构与运行机制

超时预警怎么设计

预警不是“提前把任务判定为超时”，而是在 SLA 使用率达到阈值时发出风险信号。假设任务时限为 8 个工作小时，可以在使用 80% 时提醒办理人，在使用 95% 时提醒部门负责人，在 100% 时进入正式超时处理。

有两种常见实现：

1. 模型内预警：在同一用户任务上配置多个非中断边界定时器，每个定时器对应一个预警级别。优点是语义直观、可靠性高；缺点是模型元素增多。
2. 统一 SLA 服务：任务创建时保存预警时间和截止时间，由独立服务扫描或调度通知。优点是规则集中、模型简洁；缺点是需要额外保证调度可靠性和幂等。

对于会改变流程路径的升级，例如预警后自动加签部门负责人，建议仍然使用 BPMN 定时器显式建模。对于只改变通知对象、颜色和看板等级的预警，可以由统一 SLA 服务承担。

预警时间最好在任务创建时一次计算完成并保存。若每次查询时临时计算，节假日版本变化、时区和历史规则可能导致同一任务今天与明天得到不同截止时间，审计难以解释。

超时自动审批应该怎样建模

超时自动审批通常使用中断边界定时器。定时器触发后，Flowable 取消当前用户任务，并沿定时器支线进入规则决策。自动审批不是定时器本身的功能，而是定时器触发后的一项业务决策。

<boundaryEvent id="autoDecisionTimer"
               attachedToRef="managerApproval"
               cancelActivity="true">
  <timerEventDefinition>
    <timeDate>${autoDecisionAt}</timeDate>
  </timerEventDefinition>
</boundaryEvent>

<sequenceFlow sourceRef="autoDecisionTimer" targetRef="timeoutDecision" />
<businessRuleTask id="timeoutDecision" name="超时处理规则" />

推荐的规则结果至少包含四类：

• 自动通过：只适用于风险较低、规则明确、法律与内控允许的场景。
• 自动驳回：适用于材料缺失、资格过期或“不处理即失效”的业务。
• 转人工升级：转给上级、流程管理员或专门兜底岗，是多数企业更安全的默认值。
• 终止或撤销：适用于超过业务有效期后继续审批已无意义的申请。

不要在一个通用定时任务里直接查出所有超时任务并调用“完成任务”，因为扫描结果与实际任务状态之间存在竞争：用户可能刚刚完成、转办或撤回任务。BPMN 中断定时器与用户完成操作在引擎事务和乐观锁机制下竞争，通常只有一条路径能成功，更符合流程语义。

四、核心场景与处理策略

Flowable 8 定时器底层如何执行

根据 Flowable 8.0.0 官方异步执行器说明，边界定时器创建后会保存到 ACT_RU_TIMER_JOB，其中包含到期时间、处理器类型、流程实例和执行上下文。异步执行器周期查询已经到期的定时器并加锁，随后把它转换为可执行作业，在工作线程中继续流程。

执行成功后，提醒支线或超时支线继续运行；执行失败则根据配置重试。多次失败后，作业会进入 ACT_RU_DEADLETTER_JOB，需要管理员查看异常并恢复。流程实例或定义被挂起时，相关作业会进入挂起作业表，不会继续触发。

这条执行链带来三个工程结论：

• 必须启用异步执行器。官方文档明确指出，边界定时器只有在异步执行器启用时才会触发。
• 定时器不是精确到毫秒的实时调度。触发延迟取决于获取间隔、数据库负载、线程池和队列容量。
• 通知和自动处理仍要幂等。节点故障、锁过期和重试可能导致外部系统收到重复请求。

在集群部署中，多个执行器通过数据库锁竞争作业。增加节点可以提高可用性，但获取批量过大也会增加乐观锁冲突。需要根据定时器数量、集中到期峰值、每个动作耗时和数据库性能压测，而不是只增加线程数。

到期时间发生变化时怎么办

审批过程中可能发生延期、加签、退回、转办或节假日调整。此时必须同时处理“展示截止时间”和“执行定时器”。只修改用户任务的 dueDate，不会自动把已经创建的 BPMN 定时器作业改到新时间。

Flowable 8 的管理 API提供重新安排定时器作业的能力，可以按新的固定时间、持续时间或周期更新作业。使用时必须精确定位当前任务作用域对应的定时器，记录旧时间、新时间、变更原因和操作者，并避免误改同一流程中的其他定时器。

更稳妥的规则是：

1. SLA 在任务创建时生成一份不可变基线。
2. 延期形成新的 SLA 版本，不覆盖历史记录。
3. 在一个业务操作中更新任务到期时间、重排定时器并写入审计记录。
4. 变更后立即校验运行时作业的触发时间。
5. 已经触发的提醒不删除，只标记其对应的旧 SLA 版本。

若流程允许频繁动态延期，统一 SLA 服务可能比在模型中维护大量定时器更合适，但改变流程路径的最终超时动作仍建议由 BPMN 表达。

五、数据、规则与状态设计

会签、并行网关和子流程要特别注意什么

在多实例会签中，定时器挂在哪个作用域决定它影响谁。挂在单个用户任务实例上，可能为每个会签人创建独立定时器；挂在多实例整体作用域上，则代表整个会签节点的统一截止时间。模型设计前必须明确 SLA 是“每个人进入任务后 24 小时”，还是“整个会签节点 48 小时内完成”。

中断定时器可能取消其所附着作用域内的执行。若自动审批支线挂错层级，可能只取消一个会签人的任务，也可能终止整个会签。并行网关场景下，一个分支超时不应默认取消其他已经在办的分支；如果业务要求整体超时，应把定时器挂在包围这些分支的子流程上，显式收敛执行令牌。

子流程的超时也应区分局部与整体：局部定时器只升级子流程内的当前任务；边界定时器挂在调用活动或嵌入式子流程上，才可能中断整个子流程并回到父流程的超时出口。

自动审批前必须再次读取实时状态，检查任务是否仍有效、业务单据是否撤销、流程是否挂起、是否已经由其他分支形成结论。规则决策与状态变更应尽量位于同一引擎事务中。

自动通过有哪些业务风险

“审批人不处理就默认同意”在技术上很容易实现，但在财务、合同、用印、人事和合规领域可能违反内控要求。技术方案应把自动通过视为高风险策略，而不是平台默认值。

推荐建立自动审批白名单：限定流程、节点、金额、申请类型、人员范围和风险等级；超过阈值一律升级人工。自动处理意见中要明确标识“系统因超时自动处理”，不能伪装成某个审批人操作。

审计信息至少包括：原办理人、任务创建时间、SLA 版本、预警与提醒记录、定时器计划时间、实际触发时间、规则版本、输入数据摘要、决策结果和系统身份。若规则依赖外部数据，还要保存调用结果或证据摘要。

对自动审批规则的修改应经过发布审批，并只影响新创建的定时器或明确选择的实例。不能在生产环境直接修改规则后，让所有存量任务无提示地按新口径自动通过。

六、工程实现与系统集成

消息通知怎样避免重复和轰炸

超时提醒往往同时接入站内信、短信、邮件和企业微信。流程引擎负责产生“应提醒”事件，消息中心负责模板、渠道、限流、降级和送达状态，两者不要紧耦合。

建议采用以下策略：

• 相同任务、相同级别、相同计划时间只生成一个提醒事件。
• 短时间内多条待办合并为摘要，避免一分钟收到几十条消息。
• 普通提醒优先站内信或企业微信，短信只用于高等级或临近业务失效的场景。
• 夜间和节假日遵守免打扰窗口，高风险流程可配置例外。
• 任务完成、撤回、终止后，发送前再次检查状态并取消未发送消息。
• 渠道失败由消息中心重试，流程定时器不直接无限重发短信。

通知失败通常不应回滚已经发生的超时流程动作。可以先在本地事务中写入通知事件，再由消息消费者可靠发送；若消息最终失败，进入补偿队列和运营告警。

监控和运维应该看哪些指标

一个可靠的超时系统不能只看“有多少任务超时”，还要观察定时器执行链：

指标	说明	典型告警
定时器积压量	已到期但尚未执行的作业	持续增长或超过容量基线
触发延迟	实际执行时间减计划时间	P95/P99 超过业务容忍值
死信作业数	多次失败后停止重试的作业	出现即告警并要求处置
提醒重复率	同一幂等键多次送达	超过阈值说明重试或去重异常
自动审批比例	系统自动结论占全部审批比例	突然升高可能是人员或规则异常
SLA 变更次数	延期和重排频率	频繁变更可能规避考核

运维人员还需要能按流程实例、任务和定时器作业互相定位，查看异常堆栈、剩余重试次数和锁信息，并受控地重新执行或恢复死信作业。任何人工恢复都应写入审计日志。

集中到期是常见峰值，例如每天 18:00 大量任务同时触发。设计时应避免所有流程使用同一个绝对时间，必要时分散预警批次；消息渠道也要有独立限流，不能让短信网关变慢拖住流程执行线程。

七、安全、性能与治理要求

推荐的企业级实施架构

推荐把能力分为四层：

1. SLA 规则层：定义开始时间、暂停条件、业务日历、预警比例、截止时间和自动处理策略。
2. Flowable 执行层：通过用户任务到期时间和 BPMN 定时器承载流程语义。
3. 消息与决策层：消息中心负责渠道，规则服务负责自动处理结论，二者均支持幂等和版本管理。
4. 运营治理层：提供超时看板、死信处理、SLA 变更审计和触发延迟监控。

低代码平台可以把这些能力封装为节点属性：办理时限、业务日历、预警规则、提醒对象、提醒周期、超时动作、自动审批规则和人工兜底人。设计器保存的不是一段随意脚本，而是可验证、可发布、可审计的配置，并在部署时转换为 BPMN 定时器与平台扩展属性。

云程低代码开发平台这类企业流程产品，可以进一步把办理人、部门负责人、岗位关系、消息模板和数据权限统一接入 SLA 规则，让同一套超时策略在专业 BPMN 设计器和简化审批设计器中保持一致。

上线前应完成哪些测试

测试不能真的等待两天。应通过可控时钟、分钟级测试模型或管理 API把定时器移动到可执行状态，覆盖以下场景：

1. 用户在预警前完成，所有后续定时器被正确取消。
2. 非中断提醒触发后，原任务仍可完成。
3. 用户完成与中断定时器同时发生，最终只有一条有效路径。
4. 周期提醒达到次数或结束时间后不再创建作业。
5. 作业执行失败后重试，最终失败进入死信表。
6. 节点挂起、流程挂起、恢复后定时器行为符合预期。
7. 会签、并行网关、子流程中定时器只影响目标作用域。
8. SLA 延期后，任务到期时间与定时器作业保持一致。
9. 集群节点异常后，锁过期作业可以被其他节点恢复。
10. 消息重复投递时，渠道侧只产生一次有效通知。

自动审批还要增加规则边界测试：金额临界值、人员离职、单据撤回、流程版本切换、外部数据不可用和人工兜底失败。

八、平台落地、测试与选型

常见问题

1. 只设置 flowable:dueDate 能否实现超时提醒

不能。它可以用于列表展示和 taskDueBefore 等查询，但不会自动触发通知。需要 BPMN 定时器或独立 SLA 调度服务。

2. 非中断边界定时器会删除审批任务吗

不会。cancelActivity="false" 表示触发提醒支线的同时保留原活动。默认中断型边界定时器才会取消附着活动。

3. 定时器到点为什么没有执行

首先检查异步执行器是否启用，再检查作业是否挂起、是否仍在定时器表、数据库时间与应用时间是否一致、获取线程是否积压，以及作业是否已经进入死信表。

4. 修改任务到期时间会自动修改边界定时器吗

不能依赖这种同步。任务字段和定时器作业是不同机制。延期操作应显式更新任务到期时间并重新安排对应定时器，同时记录 SLA 版本。

5. 自动审批应该直接默认通过吗

通常不应该。更安全的默认策略是升级到负责人或人工兜底。只有低风险白名单场景，经过内控确认并具备完整审计后，才允许自动通过。

如果只记住三句话

第一，dueDate 用于表示和查询截止时间，BPMN 定时器才负责到点执行。

第二，提醒与预警使用非中断定时器；改变流程结论的超时处理使用中断定时器并进入规则决策。

第三，自动审批的难点不在调用完成任务，而在业务授权、并发竞争、幂等、审计、业务日历和失败兜底。

九、结论

Flowable 已经提供可靠的 BPMN 定时器、异步执行器、作业锁、重试与死信机制。企业应优先使用这些能力表达会改变流程路径的超时规则，再用任务到期时间和统一 SLA 服务补充查询、看板和通知治理。

超时提醒的目标是促使人完成任务，超时预警的目标是提前暴露风险，超时自动审批的目标是按受控规则处理失效任务。三者对象、时点和风险完全不同，不能共用一段“查超时任务并自动完成”的定时脚本。

最稳妥的方案是：统一计算 SLA，分别保存预警时间与截止时间；用非中断定时器发送提醒；用中断定时器进入自动处理决策；用消息中心负责渠道；用运营平台监控作业积压、触发延迟和死信。这样超时能力才真正可配置、可解释、可恢复和可审计。