所谓流程系统，就是不同的人按照规则参与同一件事情的处理。比如报销审批，由报销人提出申请，再经各级主管审核，最后由财务部门核准的一个过程。工务申请，由申请人提出申请，经各经主管审核和相关部门评估，再由制作部门派工制作的一个过程。。。
今天就对流程系统消息和通知的设计分享一些想法
一般流程中的人员，特别是主管，都不会每时每刻守在系统中，等待单据或任务的到来，很多时候，流程中的人员都是在接到系统的通知后，再登录系统处理任务。因此流程的消息，就成为流程系统设计一个不可或缺的环节
第一.消息的分类
流程系统中最重要的消息，就是通知人员有任务需要处理的任务消息了，这些消息带动流程有序按时运转。
消息的内容可能像这样:"您有2张请假单需要签核，单击这里处理"
其次是知会消息，收消息的人员可能只是获得一个通知，不一定要登录系统进行作业，因此这种消息的重要性比较低
如：
您的请假单已被核准，单击这里查看
XX的请假单已被退回，单击这里查看
第二.消息何时发送
流程中的消息的都是在流程人员进行某个动作后产生，如用户送审请假单后，请假审核的任务消息就会产生，并且发送给第一个审核人员。工务单审核完后，就会发送要求派工的信息给派工人员，通知其进入系统进行派工作业。
又比如在最后一个人员审核后，请假单已被核准的知会消息，就可以向申请人发送。
知会消息一般都是这样发送
但是任务消息如果这样的话，有可能会碰到下面这些情况：
1.某人的任务单据太多，可能一天要处理几十上百个，这时候如果每笔作业都通知势必会造成用户的困扰
2.虽然大多数时候，人员依赖消息来处理任务，但是并没有排除有人主动登录系统就把任务处理掉了，这时候滞后的消息可能会干扰和迷惑用户
3.有的流程可能在运行到某一个节点时，才发现这个人员已离职，或休假，或出差，因此需要把任务替换或代理给另一个人，如果采用这种方式，则在流程动态变更后，新的流程人员就没办法收到任务处理的消息了(流程在实例运行过程中的动态变更是检验一个流程系统是否实用的很重要的标准)
因此任务消息我们采用的是
1.用户登录系统，获取最新任务（用户完全主动，不需要消息通知）
或者登录网站后，通过站内短信，定时询问是否有任务（任务系统即时计算任务）。
或者打开我们自己开发的消息客户端，定时询问是否有任务（任务系统即时计算任务）。
后两种一般都可以让用户设定间隔时间（如每隔5分钟收一次）。
在这里再分享一些客户端消息程式（站内短信或window客户端）设计的一些实际作法
消息图标有三种状态：无消息，新消息（新任务），有消息未看（或者有任务未处理）
新消息表示最新收到，最后一次定时询问时收到的消息，一般图标闪烁，提醒用户
新消息到来时，可能用户没有时间去处理，这时一般闪烁一段时间后，则变成有消息未读的图标，不再闪烁的方式干扰用户，但是也提醒用户有消息没有看，以区别无消息
但是对于任务来说，消息有没有看并不决定任务是否有没有处理，所以有消息未看，变成有任务未处理，凡是有任务未处理
则以相同的状态提醒，则不论用户有没有看
所以任务收到后，一般要比对主key，检查是否新的任务到来，再选择以何种方式提醒用户
2.任务消息除了定时获取外，有时候还需要主动通知
如超过几小时或一天未处理的，可以通过mail或手机短信等进行通知
一般通过一支排程程式，定时运行，计算任务人员，统一发送消息
第三.消息发送方式
严格来说，这个不止在流程系统的设计会遇到，在一般的系统可能也会有消息发送分为系统主动发送，和用户主动索取
1.如系统主动用mail,短信,MSN或自己开发的客户端程式通知用户，类似于推送
2.用户向系统询问消息
a.如用户登录某个网页后，网页通过ajax，定时向消息服务询问消息。
b.通过客户端程式，每隔一段时间询问消息。
对于任务消息来说
即时的待办任务，则可在用户的消息定时器轮询时，即时计算，再发给用户
催办类的任务消息本质上是知会消息，因此其处理方式与知会消息相同
对于知会消息来说
一般都通过1的方式直接推送
用户还可以选择是否接收某类消息或选择何种方式（如mail,手机短信，MSN，站内短信还是自定义的客户端）
如果选择的是站内短信或定时询问的客户端，则后者可能需要设计一个资料表来存储这些信息，等到定义询问时再发送出去
，并标记为已发或删除
如果要帮助用户管理这些信息，则可能只标记为已发(记录用户阅读时间)
如果只是发出去，由接收程式自行管理消息，则删除
系统可以设定哪些方式发，默认哪些发，哪些不能发
用户也可以在系统设定的范围内再选择以何种方式收
另外消息内容可能因接收类别不一样而不一样，
如手机短信，内容可能要精简
站内短信，可以以链接方式
邮件，内容可以比较详细
其它如消息内容的语言设定有时也需在多语言用户环境进行考虑。