很多人认为，工作流就是做审批流，上工作流系统，就是为了处理审批流。这显然是个误区，大概是给大量的oa办公系统给闹的，那套oa系统不包含一个审批流？
一套工作流系统，包含流程引擎，流程设计器，流程管理中心，甚至自定义表单。流程引擎封装好抽象的业务流程模型，流转和实现，对外提供api函数接口；流程设计器可视化的给业务流程建模，设计流程模版；流程管理中心，能模拟流程的运转，跟踪和监控流程实例；自定义表单可视化的设计业务模块；
这样的一套工作流管理系统，不仅能处理审批流，更能处理纷繁复杂的业务流程，如生产制造过程，电信服务的业务申请，银行业务办理，物流服务，配送管理等等。
当工作流系统应用于oa系统时，就会大量的处理如出差申请，加班申请，报销流程等等。因此，很多人都以能不能方便的处理审批流来作为衡量一套工作流系统的标志，显然这只是当工作流系统应用于oa办公系统时的标准，不能作为衡量一套工作流管理系统的标准。
为了适应大量的审批流和能更加方便的设计审批节点，我们在eworkflow自定义工作流管理系统中，增加了通用的审批表，使得做审批流更加方便和快捷。
流程实例id：和具体的流程实例关联
动作id: 和具体的动作节点关联
步骤轨迹id: 和流程实例的轨迹关联
分支实例id: 有分支节点时和分支关联（运用了步骤轨迹id,可以不用这个分支实例id）
其它就是常见的审核字段
当一个具体的业务流程的审批节点上挂接表单时，如下面的审批节点，挂接的eform表单: leave_check.dj
在leave_check.dj中，只要按下图中那种方式设置，和通用审批表关联上，这个表单就能完成审批的功能了。
因为和步骤轨迹id关联过
trace_id=':{$urlParam("traceId")}:'
所以当监控和跟踪查看已经审批的记录时，也能取出审核意见等信息，做显示用（已经办理过的节点不能再次执行，只能查看）。
通过一个通用审批表，能完成所有的审批节点的功能。
当然用户也可以不使用通用审批表来做审批功能，将审核字段建立在自己的业务表中，或者业务子表中，并且加上trace_id步骤轨迹id，也一样能完成审批的功能，只是这样就需要每个业务表中建立审核字段。
两种方式各有利弊：
当单独做业务记录列表时，需要显示审核人，审核结果，审核意见等信息，需要关联通用审核表去获取这些信息，如果是直接存在业务表中的，则就从业务表中获取，不需要关联。
总的来说，还是用通用审批表比较方便，可以快捷的做好审批的节点。
