在工作中有许多的业务场景都涉及到审核功能，如请假条、加班申请、采购单等。既然有这么多场景都在使用审核，那能不能将审核功能单独设计成公共模块进行复用呢？这个肯定是可以的，下面我就带大家来分析一下审核功能。

　　下图是一张常见的请假单申请单，如果我们根据操作内容来划分，可以分出两个区域：业务表单区和审核表单区。

　　审核中主要有两个角色参与其中：发起人和审核人：

　　单就审核表单来说，它提供的功能相对简单，主要有以下几个：

　　串行审批主要是指当一个审核节点通过后，才能进入下一个审核节点。如果驳回，则驳回到上一个节点、或之前任意一个节点或者业务表单编辑节点。

　　并行审核是指一个审批节点同时存在多个对象可以同时审核的情况。当其中一个、多个或全部审核通过，才能进入下一个审核节点。如果驳回，通常其中一个对象驳回，就认为当前节点被驳回，其它的情况很少使用，如多个对象驳回、全部对象驳回。具体通过或驳回需要根据业务场景而定。

　　混合审核通常是指包含了串行审批和并行审批的方式。如下图中，整个流程是一个串行审核方式，而其中一个节点则是并行审批方式。

　　对于上面的几种方式分析后，可以看出，一个审核流通常是由多个审核节点组成， 每个节点内最主要的任务是找到对应的审核人并作出相应的意见反馈。

　　发起人在发起申请时可以自己指定需要进行审核的人，这种场景比较常见。主要优点是功能简单、灵活性比较高，缺点是无法形成标准审核流程。适用于那些对审核要求不高的业务，如请假单、迟到补卡、加班等。这样的审核流因为是用户自己设置，所以通常不会太复杂。

　　企业中还有许多审核内容因为其中涉及到了金额、以及保密信息，所以上面这种人为自定义的方式就不太适用，它们的审核流程通常都是固定的标准审核流，如采购单、合同等。针对这种情况需要设计一套标准审核流程，后期由技术人员或者产品经理进行维护。

　　除了审核人外，还需要根据业务加入更多的匹配规则，如:

　　1）审核金额：即当满足一定的金额条件后，才会触发对应审核人。如企业的采购单审核，当采购金额小于等于10000时，采购主管审核即可，当大于10000时，同时需要采购经理来审核。

　　2）动态确认审核人：上面我们总结了，审核其实就是找到对应的审核人，然后完成审核信息。审核人的设置有以下几种方式：

　　3）消息通知：当审核进入对应节点的时候，给发起人和审核人发送消息通知，及时了解审核状况，通常由代码内部完成这个逻辑，功能不会体现在原型图上。

　　4）抄送人：消息发送给审核人和发起人的同时，也需要给指定抄送人发送一份。

　　下面是优化后的固定审核流原型图:

　　审核流列表页：

　　审核流设置页：

　　上面我们将审核设计成独立的功能模块，使用时可以通过下面几步完成调用：