自定义工作流状态

业务类型之间的差异，决定了该业务工作流的状态类型和状态变化的逻辑。在B端项目中，一个平台会存在多条业务路线，每条业务路线都有相对应的角色类型。也就是说每一条业务线都会有一个专属的工作流，从软件设计的角度来讲，不可能给每条业务线的工作流都定制一遍，这肯定是不符合软件设计中的可复用性原则。所以，自定义工作流设计是非常有必要的，其重要性应该是与角色权限设计同级别。

什么是工作流状态

工作流状态是指某一类业务流程中的状态定位，这个状态受业务类型和业务流程影响。状态之间可以根据一定的规则进行流转，这个规则可以是人工执行，也可以是程序条件执行。状态的数量和类型受具体业务的类型影响，没有一个固定的值，这也是为什么需要自定义工作流状态的原因。

如下图中，例举了一个任务相关业务的工作流状态。从表层上理解，就是一个状态的流转过程，这个任务状态从“未开始”到“已关闭”。深一层的理解，就是流转逻辑的控制。状态之间的流转有什么样的流转逻辑，要达到什么样的前置条件，需要由什么角色来进行操作，操作后有什么样的反馈。

自定义工作流状态设计的条件

所属业务：每一条工作流都必须有一个所属的业务类型，工作流是服务于具体业务，没有业务就不存在工作流。（需要注意的是，并不是所有工作流都一定要有状态，这篇文章主要讲带有状态的工作流。）

起始状态：起始状态是指业务流程中某一段时间的描述概括。需要注意的是，起始状态并非业务流程中的第一个状态，而是逻辑上的起始状态。业务流程中任何一个状态都可以作为起始状态。

目标状态：有了起始状态，那么，起始状态要流转的状态就是目标状态。与起始状态一样，目标状态并非特质某一种状态，业务流程中任何一个状态都可以作为目标状态。

下图示例的流转设定：未开始→进行中、已完成；进行中→已完成、已关闭；已完成→已关闭；已关闭→未开始。理论上的设定是，每一种起始状态都可以流转为任意的目标状态，但实际使用的时候还需要根据具体的业务来设定，同时程序上一般也是需要做一些限制，避免出现比较荒谬的流转。

在新增工作流状态的时候，起始状态和目标状态都会同时默认新增这一条新增的工作流状态，以确保状态流转的灵活性，也可以避免状态流转出现空缺的情况。

状态设计的原则

唯一性：一个流程中，状态的名称需要做到独一无二。这一点，在状态新建的时候程序做一下校验是非常有必要的。

概括性：状态名称的设定需要具有一定概括性，能够清晰的描述当前业务段的业务进展。

中粒度：状态的粒度需要适中。过小的粒度会导致流程复杂冗余，过大的粒度会使流程产生一些遗漏的细节。

状态流转配置

配置流转前置条件：如果该流转需要人工操作，那么需要指定操作角色/用户；如果该流转是系统自动完成，那么需要配置好完成的条件规则。

配置流转内容：状态在流转的时候，需要反映出这次流转过程中的内容信息，以更好的解释这次流转的目的。

配置后置动作：后置动作的设定有两个方面的考虑。一是为了设定流转内容的反馈方式；二是为了触发下一个状态的前置条件。

总结

工作流程状态的配置化设计表面上是几个状态标签的流转，实际在设计使用过程中核心部分在状态流转的配置上。当然，这一切的前提都离不开对业务的深刻理解，流转的配置需要业务支撑。

需要说明的是一个系统中，可配置项太多，看似做得非常灵活，实则多少会使系统变得功能冗余。用户真实关心的可能不是系统配置项有多么多么强大，反而只会觉得系统太过复杂。另外，开发成本也会增加。