流程自动触发
这项能力到底在做什么
Section titled “这项能力到底在做什么”流程自动触发，简单说，就是当某个条件满足时，系统不用再等人手动判断，就能按规则把下一步动作自动拉起来。
很多企业流程真正慢下来的地方，不是因为后面没人做，而是因为前面总要有人先判断一句：
- 这个情况要不要继续往下走
- 现在是不是该提醒了
- 这条异常要不要升级
- 这份结果能不能直接回写
- 这件事是不是该自动开下一步任务
如果这些判断天天都靠人盯，流程很快就会出现：
- 忘了触发
- 触发晚了
- 不同人判断标准不一样
- 同样条件有时触发、有时不触发
- 明明可以自动往前走，却卡在等人点一下
流程自动触发真正解决的，就是把这些重复、明确、可规则化的判断，从人工临时决定，变成系统稳定执行。
它通常接收什么输入
Section titled “它通常接收什么输入”这项能力接进来的，通常是一条“已经发生的事件”或者“一组已经满足的条件”。
常见输入包括：
- 新数据写入
- 状态变化
- 异常识别结果
- 到期时间到达
- 阈值被触发
- 某一步完成
- 某一步超时
一起带进来的上下文，常见还有这些：
- 对象编号
- 当前状态
- 触发时间
- 触发来源
- 风险等级
- 规则编号
- 允许执行的动作范围
- 是否需要人工复核
这些上下文很重要。因为自动触发不是“看见变化就动”，而是要知道：
- 是什么变化
- 哪条规则被打中了
- 该动哪一步
- 能不能直接动
它能输出什么结果
Section titled “它能输出什么结果”流程自动触发最后交出去的，不应该只是“已触发”，而应该是一份清楚说明“触发了什么、为什么触发、后面做了什么”的结果。
常见输出包括：
| 输出项 | 说明 |
|---|---|
| 触发结果 | 本次是否真的触发了后续动作 |
| 命中规则 | 是哪条规则让它往下走的 |
| 触发动作 | 创建任务、发送通知、升级、回写、拦截等 |
| 触发时间 | 什么时候触发的 |
| 对象范围 | 这次动作作用在哪个对象上 |
| 幂等状态 | 是否已经触发过，是否需要去重 |
| 执行结果 | 成功、失败、待人工确认 |
| 留痕记录 | 整个触发过程有没有被完整记录 |
这样下游拿到的，就不是一句“系统自动处理了”，而是一份可追踪、可回查的流程结果。
它在内部是怎么跑起来的
Section titled “它在内部是怎么跑起来的”流程自动触发真正难的地方，不是执行动作，而是先保证“该触发的时候一定触发，不该触发的时候不要乱动”。
它在内部通常会经过下面这条链。
1. 先接住事件或状态变化
Section titled “1. 先接住事件或状态变化”系统先知道有事情发生了。
比如某个字段变了、某条记录超时了、某条异常结果出来了、某一步流程走完了。
2. 再判断当前是否命中规则
Section titled “2. 再判断当前是否命中规则”不是所有变化都要继续往下触发。
系统通常会先判断：
- 当前状态对不对
- 风险等级够不够
- 时间条件是否满足
- 前置条件是否已经完成
- 这条规则是不是当前对象应该走的规则
3. 再检查能不能直接执行
Section titled “3. 再检查能不能直接执行”很多企业流程里，有些动作可以直接自动做，有些动作必须先卡一下。
所以系统通常还会继续看：
- 这一步是否高风险
- 是否已经触发过一次
- 是否需要人工确认
- 当前对象是否被锁定、暂停或关闭
4. 再拉起对应动作
Section titled “4. 再拉起对应动作”如果条件都满足，系统才会真正执行动作。
常见动作包括：
- 发通知
- 创任务
- 改状态
- 开工单
- 回写系统
- 升级处理
5. 再处理失败、重复和回退
Section titled “5. 再处理失败、重复和回退”真正的企业流程不会永远成功。
所以自动触发后，系统通常还要继续处理：
- 重复触发
- 下游执行失败
- 某一步被人工驳回
- 本来可以执行，后来条件又变了
6. 最后把触发过程完整记下来
Section titled “6. 最后把触发过程完整记下来”一条自动流程值不值得信，关键不只是它能跑，而是后面能不能说清楚：
- 为什么跑了
- 按哪条规则跑的
- 跑完结果是什么
- 失败时停在了哪里
所以留痕是这项能力非常关键的一部分。
流程自动触发的详细内部流程图
Section titled “流程自动触发的详细内部流程图”flowchart TB
A[输入事件或状态变化] --> B[读取对象状态、时间、风险等级、规则配置]
B --> C[判断是否命中触发条件]
C --> D{是否满足前置条件?}
D -->|否| E[不触发并记录原因]
D -->|是| F[检查是否已触发过、是否需要人工确认]
F --> G{允许直接执行吗?}
G -->|否| H[转人工确认或等待条件补齐]
G -->|是| I[执行后续动作<br/>通知 / 建任务 / 升级 / 回写 / 改状态]
I --> J[检查执行结果和下游返回状态]
J --> K{执行是否成功?}
K -->|否| L[记录失败并按规则重试或回退]
K -->|是| M[记录命中规则、执行结果和留痕]
E --> N[交给看板、复盘、审计继续使用]
H --> N
L --> N
M --> N
它最后会把什么交给下游流程
Section titled “它最后会把什么交给下游流程”流程自动触发真正交给下游的，不只是一个动作结果，而是一份完整的“触发上下文”。
常见会交出去这些内容：
- 本次是否触发成功
- 命中了哪条规则
- 触发了什么动作
- 动作作用到了哪个对象
- 是否需要后续人工接力
- 是否出现失败或重试
- 整个触发留痕
这样后面的流程才能继续做：
- 跟进处理
- 异常恢复
- 报表统计
- 责任分析
- 流程复盘
- 规则优化
它怎么接入业务才真正有价值
Section titled “它怎么接入业务才真正有价值”流程自动触发最怕的，不是触发不了，而是触发规则不稳，结果让人不敢信。
真正常见、也最有价值的接法，一般有下面几种：
1. 接在状态变化后面
Section titled “1. 接在状态变化后面”只要状态从 待处理 变成 超时，或从 正常 变成 异常，系统就自动决定下一步。
这样流程不会卡在等人手点。
2. 接在时间节点后面
Section titled “2. 接在时间节点后面”到点未完成、超时未回复、到期未关闭，这类节点特别适合自动触发。
因为规则通常清楚，而且重复量很大。
3. 接在异常识别后面
Section titled “3. 接在异常识别后面”系统先发现异常，再由自动触发去决定提醒、升级、建任务还是回写。
这样整个链条才会真正动起来。
4. 接在多系统协同前面
Section titled “4. 接在多系统协同前面”如果一条业务要跨多个系统走，自动触发能把“哪个系统先动、哪个系统后动”接起来。
这会明显减少人工搬运状态。
什么情况下必须转人工
Section titled “什么情况下必须转人工”流程自动触发虽然很适合自动化，但下面这些情况最好让人工拦一下：
- 规则本身还没定稳
- 高风险动作不能直接自动执行
- 当前对象状态冲突，系统无法安全判断
- 同一事件同时命中多条互相冲突的规则
- 下游系统执行失败，但原因不明确
- 触发对象涉及金额、审批、责任归属等敏感动作
- 当前数据明显不完整
- 自动结果和现场实际情况冲突
真正稳的企业做法，不是把所有动作都交给系统硬跑，而是把规则清楚、风险可控、重复量大的部分先自动化，把高风险动作保留人工把关。
为什么这项能力站得住
Section titled “为什么这项能力站得住”流程自动触发之所以在企业里很有价值，是因为大量流程卡点，本质上都是“下一步应该动了，但没人动”。
1. 它解决的是“流程推进靠人临时判断”
Section titled “1. 它解决的是“流程推进靠人临时判断””只要下一步总要靠人想一遍、点一下，流程就会慢、会漏、会不一致。
自动触发补的，就是这一下。
2. 它特别适合规则清楚、重复量大的节点
Section titled “2. 它特别适合规则清楚、重复量大的节点”越是高频、标准、重复的判断，越应该交给系统做。
这类动作最容易稳定见效。
3. 它能把提醒、工单、回写这些动作真正连起来
Section titled “3. 它能把提醒、工单、回写这些动作真正连起来”很多能力单独看都成立，但没有自动触发时，流程还是会断。
它的价值就在于把这些动作接成链。
4. 它边界清楚，所以更容易落地
Section titled “4. 它边界清楚，所以更容易落地”低风险动作自动跑，高风险动作人工拦。
这种分层方式很符合企业现场，也更容易让团队放心接入。