业务需求是这样的：
一个审批流，要由甲填写 A 字段，乙填写 B 字段，丙填写 C 字段；
但乙不是本组织人员，他的填写方法是在另一个系统里填写，触发 API 将数值同步到 B 字段中完成填写。
审批通过后，甲乙丙三人的审批操作日志，要能收容在同一个审批流实例中。
我的解决思路：
在审批流里放一个“监听变更”节点，主要功能与填写节点类似，除了以下 2 点：
1，能指定某一张表的某一条记录，或指定前序的“获取单条记录”节点。
2，能设置维持监听的条件，例如：A 不空且 B 为空；
审批流到达这个节点时，发现满足“维持监听”条件，就挂起等待，直到发现不再满足该条件。
可以设置最长等待时间，管理员也能介入干预，这与填写节点相同。
停止监听后，就流转到下一个节点（由丙填写 C 字段）。
我觉得这个功能非常强大，技术实现难度也不高。
既然 HAP 已有填写节点和事件触发的能力，把它俩结合一下就能搞定。
若你也需要此功能，欢迎点赞。
这个有点耗性能
是是，所以说我们都得学着点，我发帖吐槽一下工单问题，工单号、顾问姓名一个都不敢露出来，生怕万一反查去处理人家
您直接贴个工单号等船到桥头自然直，这觉悟确实高，不抱怨、不添乱，能省不少客服，又讲究又体面，我手动点赞了
你发现没，我贴了工单号，能明白其意图吗？
如果被相关负责人看到，他就可以用这个工单号去追溯我这个需求被拒绝的理由，如果理由不成立，他自然会通知我。
如果没人看到，或者理由是正当的，后续不做任何处理，这也是明道的权力，我接受。
—— 船到桥头自然直，不必到处嚷嚷。
确实，需求被拒是天经地义，提了不被拒才奇怪呢。您这不叫抱怨，叫主动完成了一次完美的拒绝闭环。您这样的带头理解，我们都得学着点，以后被拒了先反省自己，别给厂家添麻烦
这贴说的是一个具体的需求，被拒很正常呀，我没有抱怨，只是在这里告知大家而已。
明道要服务的是众多的客户，由此建立的工作机制不会因为少数几个人的意见而改动。👀️
很遗憾，被拒了，43468 工单。
这功能还能变相地实现两个审批流之间的通信，再也不用把审批流切成两半了。
比如审批流 A 到达某节点时挂起，等审批流 B 到达某节后（只需修改某个值），就能使审批流 A 继续进行。