工作表 A，新增一条记录后，点开记录详情，点击自定义动作按钮“提交申请”，会发起一个审批流程 a。
连续录入两条记录，并都提交申请，在待办里同时勾选这两条申请，点击通过。审批通过后，会将此记录中审批状态字段设为“已通过”。此时另外一个工作流 b 是基于工作表 A 的“新增或更新记录时触发”的机制，并设定触发条件为“审批状态为已通过”，此时工作流 b 已经触发并工作，执行了一系列节点的计算。但是偶尔发现虽然两条审批通过的记录触发了两次工作流 b 都运行，但计算时却漏算了其中一条记录的数据。
多次尝试，并不能被复现。不知道具体是什么原因。可有哪位大神遇到过类似情况，或者知道是什么原因造成的，这个很恐怖的，因为你不知道什么时候把数字给算错了，我们不可能每天，每次都要人工对一遍数据。
恳请大佬们赐教。
仅新增时触发工作流，是可以配置为严格串行的。
![image.png]()
感谢老师的指导，不过我还是不太能理解，即便我把记录写入到中间表，然后用中间表的新增记录触发工作流来进行计算更新，那这个中间表触发的工作流不还是一样是被同时并行触发的吗，不一样遇到并行时的问题吗？可否截图给个示范呢，谢谢。
每分钟搞一次，这样会不会太占用资源，另外，这样搞流程次数消耗不起啊。
可以定时获取去更新。 或者并发触发时，把相关记录写入到一个中间表，在中间表的新增记录工作流中进去获取计算更新，这样可以按顺序执行，也能解决。
如果不考了即时的话，可以将监听改为定时任务，每分钟去表里面取审批通过的记录，用子流程的（串行）去处理。
我还是要请教一下，当我们必须要在流程里使用计算节点对多个节点进行数据计算，然后再把结果更新时，您说的这个方法就不能用了，怎么办？因为直接用更新节点的增加计算只能选择一个节点的数据啊
您意思是最终结果肯定会正确，但日志有可能不一定和当时的执行情况完全一样？
这个日志就是说明了你之前计算并更新的过程，两条记录并发时同时读取到了一个值进行计算，以保存最晚结果为准。 现在你使用的“增加”方式，就是从数据库层面解决了这种并发保证结果准确，但是记录日志是依然是并发记录的。
这算有 Bug 吧，不稳定
估计是存日志的逻辑和你之前工作流出现计算了一个值的逻辑类似没有原子性吧。先去取基础值写入日志，然后累加值写入日志。两个流程获取基础值的时候是同一个。
按你这个方法，没太看明白计算过程，初始值时 100.69，批量审批两个流程触发了另外流程的两次执行，第一次取 100.69+0.02=100.71，第二次不是应该取 100.71+0.01=100.72 吗？怎么还是 100.69+0.01。但最后结果是 100.72 又是正确的，实在是搞不懂怎么回事了。求教
![image.png]()
想再请教一下，对于我这个批量审批通过后，另外一个工作流被同时触发的场景，如果需要用到 fx 计算节点了怎么办，他可能要计算好几个节点的数据，然后再更新字段值。这样不还是会出现我同样遇到的情况吗？
谢谢大师，我来测试一下
是啊，就怕出错
这个要仔细一点啊！
累加时，不要先查询现有 + 新值，直接用更新节点的"增加"，直接在原有基础上“增加”。![image.png]()
执行日志看了，都执行了，但就是数值计算错了。就是同时触发造成的。
查看下那两条数据的执行日志，看看分别执行的分支逻辑
我的查询节点只能查询到一条记录，然后取这条记录的某个字段值用来和触发工作表的某个字段值相加，再更新到这个查询节点的那个字段值。流程图如下：
![image.png]()
请问，这样的查询方式有什么问题呢？
串行时：读到 ABC，写入 3；读到 ABCD，写入 4。—— 最终是 4。
并行时可能变成：读到 ABC，读到 ABCD，写入 4，写入 3。—— 最终是 3。
建议改成：读到 A，写入 1；读到 1 和 B，写入 2；读到 2 和 C，写入 3；读到 3 和 D，写入 4。
大概率是因为查询方式问题，导致其中一条没获取到，两个出发获取的是同一条记录。
不是有数据行的更新日志吗？
严格串行速度最慢，最关键的是对已有工作流无法修改他的串/并行模式呢。
严格串行呢