做任何事情之前要先把事情搞清楚，把概念搞清楚，做软件尤其如此。概念理不清，事就说不清，给出的方法也是混乱的。
下面我们理一下工作流的几个概念。
工作流本质是协同工作，一些人遵循一定的顺序，工作要求，共同完成一项任务。
任务的种类是多种多样的，既可以是简单的事项申请（比如请假），也可以是复杂的业务处理（预算编制）。
为何很多人提习惯称工作流为审批流，是因为开始主要应用于事项审批。
但是我们从认识上一定不要局限于审批，否则就限制了我们的思路，设计出来的东西就失去了普适性，不能满足复杂的场景，勉强能应付，也是别别扭扭。比如在一个流程中，一个节点是合同备案，需要合同管理岗上传盖章生效的合同文本扫描上传。客户就纳闷：这里为啥叫“批准”呢，应该叫“完成”啊。但是我们的系统没法改，开发人员也不认为这是问题：“审批”怎么了，又不影响你使用。这本质上是对工作流认识不足，有局限性的表现。
我们理一下工作流的几个概念。
1，工作流，代表现实工作流程，包括工作环节，以及环节的时间顺序，环节的发生条件，每个环节的责任人，每个环节的工作内容和要求。一个工作流表示一类业务。
2，节点，表示一个工作环节，代表该业务的某个步骤。一类业务总是被划分为有序的几个步骤。
3，路径，节点之间的有方向的连线，表示工作环节的先后顺序，以及执行条件（又称路由条件）
4，任务，工作流产生的待完成的工作，常被称为流程代办，待办任务等等。工作流推进到某个节点后，会产生该节点的工作任务，工作任务会指定到具体的参与者。每个节点只产生一类任务。任务根据参与者多少分两类：单人任务和多人任务。不比如录入入库单的任务一般是单人任务，而投票通常是多人任务。一个节点只有一类也只会产生一个任务，即便这个任务的参与者有多人。
关于任务，我们要分开两个概念：任务状态，任务完成状态。
任务状态是工作流系统的概念，属于任务的元数据。包分为：
（1）等待完成，等待处理的任务。
（2）认领，任务被某个参与者占有。被领用的任务不可被其他人认领。
（3）挂起，认领的子状态。
（4）撤销，任务失效，不在执行。
（5）完成，被参与者完成。完成的任务不可再次执行。
任务完成状态，表示已经处理完的任务的完成结果，比如一个审核任务的完成后，状态有两个：批准，不批准。复杂的任务的完成可能多于2个，这个和具体的任务类型有关系。
以上两个状态请一定要分清楚，否则做出来工作流不伦不类，概念模糊，乱七八糟，让人费解。
5，参与者，指任务的执行者，即可以是实际的人，也可以是系统角色。每个任务的执行者在节点上定义，定义可以简单也可以很复杂。参与者可以是一个，也可以是多个（比如投票任务可以有多个参与者）。
6，任务程序，无论是实际参与者还是系统参与者，都是通过程序功能来完成任务。程序可以是有界面交互的程序（比如入库单录入界面，审核任务处理界面），也可以是无界面的程序（如数据发送任务的接口调用程序，邮件发送任务的发送程序）。每类任务都会在工作流中指定其处理程序。在参与者“打开/执行”任务时，系统会自动打开对应的任务处理程序，比如入库单录入界面，邮件发送程序来完成任务。
任务的参数和返回值。任务有入口参数，参数会传给任务处理程序，比如将单据号传给审核任务，将邮件内容传给邮件发送程序。任务的参数在工作流的节点上定义任务处理程序的时候指定。任务执行完后会有返回值，表示任务的执行状态，返回值会返回给工作流任务调度程序，工作流根据任务的返回值决定下一步的走向：往下推进还是退回到某个节点。这个处理逻辑也是工作流定义的一部分。举例来讲，简单的审核处理程序会有两个处执行结果：通过，驳回（系统可以用1和0表示），工作流就可以根据1和0执行不同的处理，要么推进到下一个节点，要么退回到开始节点。
7，事项。每个工作流处理的都是一个事项。比如请假单流程处理的是员工请假的事项，合同流程时处理的合同签约的事项。这些事项，根据企业内部管理要求，都拆分成若干步骤。这些步骤联合起来共同完成这个“事项”。
8，表单，事项在系统中的载体，可能简单，也可能很复杂。简单的如同上面说的 请假事项，“请假单”，就代表了这个业务事项；复杂的有入职流程，涉及到很多部门，人事部，财务部，资产管理部，信息部，数据也很复杂，入职信息，薪酬数据，工资卡，设备领用，信息账号等等。这些信息可以放在同一个表单上，也可以在不同的表单，比如人员信息单，设备领用单，邮箱地址创建申请单等等。不同的单据有不同岗位创建，审批，但都属于同一个“大的”事项：员工入职。因此在不同的节点，任务处理程序各不相同。
搞清楚以上概念非常重要。否则就会出现我们的工作流，要get某个人的待办事项都要废个老鼻子劲了。
