对于多人协作的工作流来说，其每一个角色都是数据的生成者，每一个角色也都是数据的处理者。这个时候，类似于流程审批类的处理权限控制就没有必要设计了。因为每一个流程操作的内容划分的都很明确，流程与流程之间的操作并没有重叠之处，上一个流程的操作只是作为一个流程的前置支撑而已。所以在这个时候，要处理好的是角色之间的功能拆分，确保每一个角色每一个流程所进行的操作都是在流程下的充分必要条件。

　　关于数据的消费，指的是数据产生后是为了做什么。对于不同的角色来说数据的产生有着不同的功能，在设计工作流的时候，也要适当的把这些考虑进去。因为我们设计的时候往往只关注数据的生成，而不去关注生成之后他要去做什么。

　　比如我最近在做的一套商管系统，签订合同完成后是为了生成店铺，进行店铺的操作，所以数据审批完成后就应该抄送一份给店铺管理的角色。

　　比如某些采购单审批通过了 ，可能消费数据的并不是采购货物的人员，还有财务人员需要进行入账处理，所以数据应该也给财务一份。所以我们在设计工作流的时候，不仅仅要考虑到数据在整个工作流中的直接消费者，其间接消费者也应当进行考虑设计。

　　第二、不同情况的工作流状态

　　一般来说，一个审批类工作流的状态只从流程上来说的话大致可以分为这几个阶段：未审批–审批中–审批结束。不同的阶段又可以拆分成不同的情况。

　　比如在未审批的情况下，可能会有已经填写但是未提交到工作流的情况，也可能会有已经提交到工作流但是发现提交内容出错无法撤回的情况。所以在审批的情况下，视情况可以添加保存的操作(对应的工作流状态可为未提交);紧急撤回的操作(对应的工作流状态可为已撤回)。

　　在审批中，除了正常的一个节点一个节点的审核外，可能会遇到的情况还会有该条工作流流转到这里时已经废弃了，此时可以加上废弃的操作(对应的工作流状态可为已废弃);还有可能流转到这里时发现整个流程有问题或者由于其他原因对于整个工作流有异议，但是可能该节点还有其他角色可以进行操作，所以需要将工作流暂时冻结，待确定后再重新激活，所以此时工作流应该加冻结/挂起的操作(对应的工作流可为已冻结)，以及对应的重新激活的操作(对应的工作流状态展示即回到原有工作流的状态)。

　　同时，在审批中可能因为会有多个工作流的操作，但是这条操作比较着急，所以在数据的生产者端可以加上加急处理的操作，此时在处理者中看到的此条记录应当为置顶状态。但是由于加急处理的权重比较高，所以并不是每一个角色都赋予这个操作权限。最后，应该给审批中设置一个审批时效，超时后是应当进行超时作废还是超时退回也应该有明确的目标。

　　最后，是审批结束，其也分为两种情况：

　　一种是审批通过，一种是审批不通过。对于审批通过，即为该条记录生成完成，可进行消费者的抄送等等操作，审批不通过，一般可以为驳回状态。对于驳回状态，设计者需要考虑的是完全驳回还是驳回到上一个节点。

　　如果是完全驳回，则需要操作者重新填写提交。如果是驳回到上一个节点，则上个节点的处理者应该有数据的编辑权限，由其进行二次编辑后重新提交其优点时流程较为优化，时间可缩短，缺点为并不是所有的处理者都有编辑权限，逻辑方面需要设计者思考。

　　对于协同工作类的工作流，工作流的状态相对来说就是比较简单的了，其每一个流程节点都是独立的，只有上一个节点的工作完全完成后，才可以流转到下个节点，而且由于其没有存在审批流的功能，所以在该节点填写完成，提交至下一节点后当前节点的工作的工作就完成了。到下一个节点时与上一个节点逻辑相同直至结束。

　　三、工作流程的制订及角色的划分

　　这一点只针对审批类的工作流进行阐述。

　　传统的工作流程来说大致可以分为这样几种情况：自由/半自由流程、固定流程、分支流程、并发流程与执行、并发流程或执行。

　　自由流程指的是从生产者到处理者每一个流程节点都可以由上个节点的操作者指定角色，半自由流程指的是指定角色的时候限定一定的范围。固定流程指的是流程是所有的流程即角色都是固定好的，不能修改。

　　这种情况的优点和缺点都极度的明显：优点即操作简单，逻辑简单，开发难度小。缺点为实用性较小，较为死板，不够灵活。

　　分支流程指的是当流程满足某一个跳转条件时即进行流程的跳转执行子流程，当流程执行完毕后再跳回到主流程进行接下来的流程操作。

　　比如某次采购单的采购，当采购金额小于100万时需要采购经理即可进行审批，当大于100万时需要副总级别的人物进行审批后才可以进行。