一项工作流发起后，会有多个部门协同办理将意见汇集后再次提交至下一个节点。这种流程使用较为普遍，如果处理方式选择不当，则会导致流转过程中产生不必要的麻烦。下面简化这一流程只摘取关键部分予以说明：

该流程由【发起人】发起后，流向了【项目部】，同时流向了【人事部】以协同判断申请人是否存在人事方面的问题。人事部处理后又流向了【项目部】，项目部确认后流向最后的【总经理】节点。这是流程的基本说明。

那么节点的处理方式该怎么设置呢？如果所有的节点处理方式都设置了默认的【抢先】该工作流会怎么流转呢？下面按此设置进行分析：

【申请人】提交后，【项目部】和【人事部】会同时各自分别收到1条工作流待办任务。

【项目部】提交后，【总经理】收到1条待办任务。

【人事部】提交后，【项目部】收到1条待办任务。

【项目部】再提交，【总经理】再收1条待办任务。

此时：【申请人】【项目部】【人事部】均已办理完成，【项目部】办理了2条任务，【人事部】办理了1条任务。【总经理】则有2条待办任务。

如果您是总经理，会怎么想？

那么怎么避免【总经理】收到两条待办任务呢？

其实很简单，只要将【项目部】的处理方式设置为【会签】就行。如果照此设置，则会是下面的流转方式：

【申请人】提交后，【项目部】和【人事部】各自收到1条工作流待办任务。

【项目部】办理提交时，则会提示【上一节点没有全部完成，不能进行办理】的提示，需要【人事部】办理完成后，【项目部】才可以提交办理。

【人事部】提交办理。

【项目部】提交办理。

【总经理】有1条待办任务。

这就是工作流处理方式【会签】的设置，设置了会签的节点，只有所有流向会签的上一级节点都办理完成后，会签才能办理。

一项工作流发起后，会有多个部门协同办理将意见汇集后再次提交至下一个节点。这种流程使用较为普遍，如果处理方式选择不当，则会导致流转过程中产生不必要的麻烦。下面简化这一流程只摘取关键部分予以说明：

该流程由【发起人】发起后，流向了【项目部】，同时流向了【人事部】以协同判断申请人是否存在人事方面的问题。人事部处理后又流向了【项目部】，项目部确认后流向最后的【总经理】节点。这是流程的基本说明。

那么节点的处理方式该怎么设置呢？如果所有的节点处理方式都设置了默认的【抢先】该工作流会怎么流转呢？下面按此设置进行分析：

【申请人】提交后，【项目部】和【人事部】会同时各自分别收到1条工作流待办任务。

【项目部】提交后，【总经理】收到1条待办任务。

【人事部】提交后，【项目部】收到1条待办任务。

【项目部】再提交，【总经理】再收1条待办任务。

此时：【申请人】【项目部】【人事部】均已办理完成，【项目部】办理了2条任务，【人事部】办理了1条任务。【总经理】则有2条待办任务。

如果您是总经理，会怎么想？

那么怎么避免【总经理】收到两条待办任务呢？

其实很简单，只要将【项目部】的处理方式设置为【会签】就行。如果照此设置，则会是下面的流转方式：

【申请人】提交后，【项目部】和【人事部】各自收到1条工作流待办任务。

【项目部】办理提交时，则会提示【上一节点没有全部完成，不能进行办理】的提示，需要【人事部】办理完成后，【项目部】才可以提交办理。

【人事部】提交办理。

【项目部】提交办理。

【总经理】有1条待办任务。

这就是工作流处理方式【会签】的设置，设置了会签的节点，只有所有流向会签的上一级节点都办理完成后，会签才能办理。