让我们很快切入正题。引入工作流的意义大家都很清楚：将不断变化的处理流程独立出来，以降低开发成本、维护成本，或是其它的东西。那么能达到一种什么样的效果，对于我们这些初次使用的人们来讲更多的是良好的期盼，因为对于WF的应用确实不是一件很容易做的事情。在此之间的一系列文章也只是对一些技术点的探索。现在终于可以整合一下了。
这里拿我们的一个实际需要进行阐述。电台、电视台里的稿件审核流程是一件非常严肃的事情，每个台都有自己一套自己的审核流程，即使一个分台可能视稿件的重要程度、紧急程度、稿件内容的不同有不同的审核流程。举例如下：
l 常规审核流程：一级一级的自下往上审核。如编辑审à科组长审à分台审à总台审。
l 终审制：是常规审核流程的一种扩展。即每个环节都有最终审核权。只要该环节认为没有必要让上级（领导）进行审核，则可以进行此操作。
l 跨 审：存在这样的情况，流程中的某一环节因为某种原因（可能相关人员请假了）而导致流程无法运行下去。有两种解决方法：一种是通过延时活动在等待一定时间 后，自动将活动跳转到下一个处理环节中去，这种方式的缺点是必需等待；另一种操作方式是，下一个要处理环节的相关人员可以直接审核上一个环节所涉及的稿件 内容，这种审核方式即跨审是一种更为及时的操作方式。
每一个环节的审核又可能有下面的表决方式：
l 权重值性要求：环节中参与的每一个用户都有一个权重值。当同意权重值之和达到一定期望值后，则该环节通过。或者反对权重值之和达到一定的期望值则认为是未通过审核。
l 角色性要求。如：某一环节要求五个编辑中的三个如果同意则进入下一个环节，如果有两个表示反对则打回。另一个例子：只要有两个副台或一个正台同意则通过，只要有一个副台或一个正台否决则打回。
l 人员性要求。这个相对简单，只要指定可参与的人员列表，及通过人数和否决人数即可。
如何有效地让客户自已去灵活地、随时随地地设计使用这些流程，而不需要工程人员或售后人员的干预是一个非常棘手的问题。客户关心的是流程中有几个环节。如果让用户自己去用IFELSE或WHILE去设计每一个环节的详细内容，则客户很快会否决这套系统，即使是技术熟练的工程人员也会皱眉的，维护成本会大幅的攀升的，而且开发人员还要为工作流设计器中的每一个条件做一些复杂和额外的工作。
理 想的情况是这样的。用户所面对的工作流设计器非常简单的：他们可以从工具箱中插入一个活动到到工作流编辑界面中去，每一活动所代表的是一个完整的处理环 节，而不是处理环节中的一部分；这就是简化用户设计的关键所在。用户不需要为设计一个具体环节的逻辑而感动头痛，他们所做的只是设置一下与业务相关的活动 的属性就可以了。这样设计出来的工作流看起来会非常的直观、简练。
要让用户有这样的用户体验，我们得需要进行大量的工作。其主要内容简列如下。
l 工作流编辑器
l 自定义的审核活动
l 基于工作流的工件维护框架
l 工作流设计管理框架
l 分布式部署的要求
然而要将这些有机的组合在一起，使之在不同的应用系统中进行应用，这就是业务工作流平台的概念了。