企业的业务处理过程如果简单，不繁琐，几步就处理完成了的，不会考虑上工作流系统。如果处理过程繁杂，处理步骤很多，涉及到很多工序，而且处理时间很长，就必须用工作流系统了。统一管理，统一运行，无论处理的过程以及路由如何繁杂，这都是工作流系统最擅长的了。并且后续的维护、修改、变更也能快速的相应。这些是用硬编码的方式来实现无法比拟的。
企业选用工作流系统，还有一种情况，当企业的业务处理种类很多，虽然每种业务的处理过程不复杂，但是种类太多，用硬编码的方式来控制流转工作量太大，多一种业务处理过程就需要做技术人员扑上去，开发，测试，发布，部署，试运行一次，而且后续的维护和修改更加无法控制，这样企业也是无法忍受的。
用工作流系统统一建模，将业务处理过程图形化的方式展现出来，一个业务办理的过程用流程中的一个节点表示，有多少个业务办理过程，就有多少个流程节点。
工作流引擎是业务流程的抽象，将业务数据和流程处理过程剥离，流程引擎只负责业务流程的流转，包含节点与节点之间的各种路由方式，条件路由，循环路由，分支，合并，子流程等等。
在工作流软件产品中就表现为，业务流程的流转用流程设计器来建模，将业务的流转办理过程用流程的节点来表示。业务办理过程，在节点上挂接的业务表中处理，包含读写展现业务数据，工作流引擎是不关心业务数据的，就是说节点上办理的是何种业务，工作流引擎是不必要知道的，这样来达到业务数据和流程的流转剥离。但是，工作流引擎在处理业务流程的流转时，有时候需要一些业务数据的参与（如条件路由，就需要取业务数据，如报销金额>10000这样的条件，这个报销金额就是业务数据），这就需要将业务数据做为实时的变量，传递到流程引擎的上下文中，使得流程引擎能读取到。所以我们经常说 业务数据和流程数据是交互的，既要分开又要有关联。
当一个业务流程建模好了，并且业务表单也挂接上了，就可以运行了，运行的顺序按流程建模的节点顺序向前流转。
运行的结果可以在流程的运行轨迹图上面直接查看，当前运行到那里了，走过的轨迹也有图形的方式查看。每个节点上办理的业务，通过双击节点，打开表单，还原当时的业务数据。双击当前正在办理的节点，打开表单，办理这个节点上的业务。提交后，这个节点任务就办理完成，从轨迹图上面又可查询到，当前运行和流转到那里了。
这种的流程运行方式，在常见的生产制作等等行业都是很实用的。通常在审批流中，不是很有用，审批流的流转通常是给下一步的办理人发送一条需要审批的待办事项（待办任务），具有审批权限的人登录到系统后，在我的待办任务中，查看到待办事项，点击进去执行审批。
当一个业务流程的办理节点数很多，或者说一个业务流程实例一启动，办理的过程就是几个月。那么这种类型的流程节点数量一定会很多。用流程建模的工具来查看或者编辑，会显得有些笨拙，节点数量大多，一个界面都放不下，这种情况，我们通常可以有选择性的用子流程的方式来分解，这样使得界面更简洁。
