工作流系统里催办功能设计：站内信、短信、邮件和企业微信

催办的本质是“对仍然有效的待办进行触达和升级”，不是替审批人作出结论，也不应该直接推动流程令牌。一个可靠的工作流催办系统，应把 Flowable 的任务到期时间、催办规则、收件人解析、消息模板、四类渠道适配器、重试与审计拆成独立能力，并用 Outbox 和幂等键隔离流程事务与外部消息服务。

如果只给出一句选型建议：站内信负责形成权威记录，企业微信负责日常高频触达，短信用于紧急兜底，邮件承载长内容；“发送成功、送达、已读、点击、审批完成”必须分别记录，不能混为一个状态。

一、核心结论与问题边界

先给答案：催办只负责触达，不负责审批

催办是针对未完成任务发出的提醒事件。它可以由发起人手工触发，也可以在到期前、到期时或逾期后自动触发。催办成功只说明系统完成了一次触达尝试，不代表审批人已阅读，更不代表任务已经完成。

工程上应坚持三条边界：第一，催办不调用 TaskService.complete；第二，催办失败不能回滚已经成功提交的审批事务；第三，外部渠道返回成功，只能更新该渠道的受理状态，不能直接把业务记录写成“已读”。

催办、超时、升级和转办有什么区别

最常见的错误，是把“逾期三小时提醒主管”实现成任务转办，或者在短信发送成功后自动完成任务。前者改变了责任归属，后者绕过了审批结论，两者都破坏审计语义。

催办从哪里触发

企业工作流通常有四类触发源：发起人或管理员点击“催办”；任务到期前的预提醒；到达 dueDate 时的到期提醒；逾期后的分级升级。触发条件至少包含流程、节点、任务优先级、业务金额、逾期时长和工作日历。

自动规则不要按固定分钟直接轮询全量任务。更稳妥的方式是按下一触发时间建立索引，分页领取到期计划；领取时再次检查任务是否仍然存在、是否已暂停、办理人是否改变，并将当次收件人快照写入催办实例。

二、关键概念与能力差异

四种消息渠道应该怎样分工

图 1：站内信保存权威记录，企业微信承担常用触达，短信和邮件按场景补位。

四个渠道不是同时全开。典型策略是：创建待办时写站内信并发企业微信；到期仍未处理时再次企业微信提醒；高优先级任务逾期后才发送短信；需要完整材料时增加邮件。

站内信为什么应当成为权威记录

站内信与工作流系统共享账号、权限和审计域，最适合保存完整的催办标题、业务摘要、任务链接、发件人、发送时间、已读时间和点击时间。外部渠道只需要携带最少信息和安全链接，详情进入系统后再按数据权限展示。

“未读”必须由接收人打开消息或待办详情后更新，不能在消息入库时写成已读。对于多人候选任务，应先明确是提醒所有候选人，还是仅提醒已签收的办理人；否则同一条催办可能制造大量无责任人的噪声。

短信适合什么场景

短信适合高优先级、强时效和外勤人员场景，不适合作为所有待办的默认渠道。正文应控制为“事项类型 + 截止时间 + 安全短链”，避免放姓名之外的敏感业务数据，更不能直接展示薪资、身份证号、合同金额等字段。

平台需要管理短信签名、报备模板、供应商、计费、频控、退订或黑名单策略。供应商返回“已受理”不等于手机实际收到；只有供应商支持并回传送达报告时，才能单独记录 DELIVERED，而且失败回执也应保留原始错误码。

三、模型架构与运行机制

邮件适合什么场景

邮件适合发送较长的审批摘要、制度说明和材料链接。附件不宜直接复制业务文件，优先提供有时效、可审计、再次鉴权的下载链接。HTML 邮件还应提供纯文本替代内容，并在主题中带上流程类型和截止时间。

邮件服务器接受投递不等于进入收件箱，图片像素统计的“打开”也会受到隐私保护、缓存和客户端策略影响。因此邮件指标应区分接受、退信、点击和系统内查看，不能用“打开率”证明审批人已经知悉。

企业微信接入要注意什么

企业微信自建应用通常通过 corpid 与应用 secret 获取 access_token，再使用发送应用消息接口，按成员、部门或标签指定接收范围。令牌只能保存在服务端，应按企业和应用分别缓存，并支持失效后刷新；secret 不能下发到浏览器或移动端。

用于催办时，文本卡片宜只展示事项名称、发起人、截止时间和“进入待办”链接。接口响应中的错误码、无效成员列表和消息标识要进入投递记录。接口返回成功表示平台受理了请求，不代表接收人已阅读；真正的阅读或点击应通过系统链接回跳、站内消息状态或受支持的回调另行确认。

多渠道路由不能写成四个 if

路由策略至少要考虑任务等级、用户偏好、工作时间、组织、成本预算和前序渠道结果。建议把渠道顺序配置成策略，而不是写死在业务代码中，例如：

1. 普通任务：站内信 + 企业微信。
2. 到期未办：企业微信再次提醒，进入两小时冷却期。
3. 高优先级逾期：增加短信，并抄送直属主管的站内信。
4. 长材料审批：增加邮件，但仍以系统详情页为权威内容。
5. 夜间非紧急任务：延迟到下一工作时段发送。

每个渠道都要有租户开关、人员可达性判断和降级路线。没有手机号就不能把短信失败当作系统异常；企业微信成员映射缺失时，可以回落到站内信并生成数据治理告警。

四、核心场景与处理策略

Flowable 8 的到期时间能提供什么

截至 2026 年 8 月，Flowable 最新正式版本为 8.0.0。官方文档说明，用户任务可通过 flowable:dueDate 在创建时计算到期时间，运行中也可调用 TaskService.setDueDate(taskId, dueDate) 修改。TaskQuery 提供 taskDueBefore、taskDueAfter 和 taskDueDate，适合筛选即将到期或已经逾期的运行时任务。

Date now = new Date();
List<Task> overdue = taskService.createTaskQuery()
    .active()
    .taskDueBefore(now)
    .orderByTaskDueDate().asc()
    .listPage(0, 200);

dueDate 是任务期限，不是催办次数，也不会自动发送消息。业务侧仍需结合工作日历、暂停时间、节点 SLA 和催办规则计算 nextTriggerTime。任务完成、删除、跳转或办理人变化后，催办实例必须在发送前再次校验，避免向旧办理人发送过期链接。

BPMN 定时器还是平台调度器

图 2：改变流程路径的超时规则放在 BPMN；仅负责触达的催办优先由平台调度。

Flowable 的边界定时器是流程模型的一部分，触发依赖异步执行器。它适合“到期后进入升级审批”“超时自动关闭”等会改变流程路径、必须随流程版本发布的规则。非中断边界定时器也能用于周期提醒，但大量节点、多人任务和高频重复周期会增加定时作业数量和运维复杂度。

如果规则只是“到期前一天发消息、逾期后每四小时提醒一次”，平台级催办调度器通常更灵活：规则可在线调整，能统一频控、静默时段、预算和渠道降级，也不会把消息供应商逻辑塞进 BPMN。两种方式可以并存，但同一个提醒只应有一个权威触发源。

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

统一催办架构应该怎样设计

图 3：流程事务只产生可靠事件，消息服务独立解析收件人、路由渠道并记录投递结果。

推荐把系统拆成六层：触发层识别手工、到期与升级事件；规则层计算冷却期和渠道顺序；收件人层解析办理人、候选人和主管；消息层渲染模板并写 Outbox；通道层对接站内信、短信、邮件和企业微信；观测层汇总成本、失败、点击和逾期转化。

流程引擎与消息供应商不能处在一个长事务里。审批事务提交时只写催办事件或 Outbox；消费者异步发送，失败按策略重试。这样短信超时、邮件服务器故障或企业微信限流都不会锁住 Flowable 的运行时表。

Outbox、幂等和重试怎样配合

同一催办可能因为调度器抢占、消费者重启或网络超时被重复执行。幂等键可采用 taskId + ruleId + triggerWindow + recipientId + channel，并建立唯一约束。消息供应商支持客户端请求号时，应同时传递稳定请求号。

重试只针对可恢复错误，例如网络超时、限流和临时服务不可用；无效手机号、收件人不在应用可见范围、模板未审核等应直接进入不可重试状态。重试采用指数退避并设置上限，最终失败进入死信队列和人工处理台。

六、工程实现与系统集成

消息状态为什么不能只有成功和失败

图 4：受理、送达、阅读、点击和审批完成是不同层级的事实。

建议将催办实例与投递明细分开。一个实例可以对应多人、多渠道；任一渠道失败不应覆盖其他渠道的成功结果。聚合状态可以是 PROCESSING、PARTIAL_SUCCESS、SUCCESS 和 FAILED，渠道明细则记录 CREATED、ACCEPTED、DELIVERED、FAILED。READ、CLICKED 和 TASK_COMPLETED 作为独立时间点保存。

关键数据表可以保持精简：催办规则保存触发与路由配置；催办实例保存一次业务触发；收件人快照保存当时责任关系；投递明细保存每个渠道请求与响应；Outbox 保存等待发布的可靠事件。原始响应要脱敏，手机号和邮箱建议加密存储并按权限查看。

收件人、权限和链接如何保证安全

收件人解析应在触发时形成快照，但发送前再次校验任务归属。已签收任务默认提醒 assignee；未签收候选任务可以提醒候选组负责人或按组织规则选定责任人，不建议无差别广播整个候选组。升级对象应由组织服务解析，并保留“为何收到”的依据。

外部消息只放最少字段。链接使用短时票据，但票据不能代替登录和数据权限校验；用户打开后仍需验证租户、身份、任务可见性和当前状态。链接过期、任务已办或办理人已变更时，应显示明确提示而不是泄露原详情。

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

手工催办怎样防止骚扰

手工催办必须记录操作人、理由、任务、收件人、渠道和时间。发起人通常只能催自己发起且仍在运行的流程；管理员可跨流程操作，但应受角色和数据范围控制。产品界面需要显示最近催办时间、剩余冷却时间和历史结果。

防骚扰策略包括：同一任务和收件人在冷却期内只发送一次；每日渠道上限；非紧急消息遵守静默时段；批量催办需要二次确认；连续多次无响应后升级主管，而不是无限重复发给原办理人。

怎样做监控、成本和效果评估

至少监控触发数、去重数、发送量、供应商受理率、送达失败率、重试次数、死信数、点击率、催办后完成时长和单渠道成本。技术指标反映通道健康，业务指标回答“提醒之后是否更快完成”。

不要单看发送量。某部门催办很多，可能是审批人不积极，也可能是 SLA 设置错误、候选人解析失效或流程节点本身不合理。报表应支持按流程、节点、组织、规则、渠道和时间段下钻，并把高频催办作为流程优化信号。

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

低代码平台怎样把催办做成可配置能力

成熟的低代码工作流平台不应让每个项目重复编写短信、邮件和企业微信代码。可以把催办规则设计成节点属性：选择触发时间、工作日历、收件人范围、渠道优先级、模板、冷却期和升级链；发布时校验模板变量、渠道凭证和人员映射。

云程低代码开发平台可以在 Flowable 之上统一承接节点 SLA、消息中心、渠道连接器、组织解析、模板中心和审计报表。其价值不在于替代 Flowable 的任务状态，而在于把引擎没有直接提供的企业消息治理能力产品化。

上线前应测试哪些异常场景

1. 催办创建后，任务在发送前已经完成、跳转或被撤销。
2. 办理人刚刚变更，旧收件人不得继续收到敏感内容。
3. 调度器多实例同时抢占同一计划，唯一键能否阻止重复发送。
4. 企业微信令牌失效、短信限流、邮件退信时是否正确重试或降级。
5. 多渠道部分成功时，聚合状态和人工界面是否准确。
6. 用户点击过期链接、跨租户链接或已办任务时是否重新鉴权。
7. 节假日、夏令时、跨时区和任务暂停后，下一触发时间是否正确。
8. 批量催办、高峰期和供应商长时间不可用时是否形成消息堆积。

九、如果只记住五句话

1. 催办是消息触达，不是审批动作，不能直接完成或改变 Flowable 任务。
2. 站内信做权威记录，企业微信做主触达，短信做紧急兜底，邮件承载长内容。
3. dueDate 只表示任务期限；改变路径的超时规则用 BPMN 定时器，普通提醒优先用平台调度器。
4. 流程事务只写 Outbox，外部消息异步发送，并用幂等键、冷却期、重试和死信保证可靠性。
5. “接口受理、送达、已读、点击、任务完成”必须分层记录，任何一个都不能互相冒充。