电子邮件通知模式捕获工作流模型如何包含将案例通知流程参与者或其他涉众的任务。这些通知通常包括流程结果或其他状态更新。本文介绍了一些协作工作流模式。
本文是一系列工作流建模模式的一部分:
被拒绝的通知
该流程的目标是发送一个标准通知批准被拒绝后，通知申请批复的人。例如员工的请求，例如休假请求或者旅行许可。
对于许多类型的请求，立即自动回复比稍后到达的个人手写回复更有价值。有时，提出请求的人更希望在审查人员做出决定后立即了解拒绝的情况，特别是在组织内部，当请求者不需要任何进一步的解释，或者当审查人员没有时间手动回复时。
该模式具有以下结构，在Signavio Workflow流程中实现。
拒绝通知是管理批准模式的一种变体，它使用自动发送电子邮件任务来处理拒绝请求的决定。此通知任务通常(但不一定)使用End Event结束流。
结束审批流程的自动通知可能不包括足够的信息来满足请求批准的人，例如当通知不包括决定的原因时。这可能会产生流程模型没有考虑到的“故障需求”。
结果通知
流程目标是发送标准通知，说明流程已实现其目标，并向案例参与者提供详细信息。例如采购请求:一个成功的商务旅行请求会产生航班预订详细信息(日期、航空公司、航班号、预订参考)，提出请求的员工随后可以使用这些信息办理航班登记。
有时，工作流会产生发起者需要的一些信息，例如某个决定或某些已完成工作的细节。这种“请求响应”过程在发起者收到结果时结束。自动化最后一步可以减少工作流所需的时间。
该模式具有以下结构，在Signavio Workflow流程中实现。
该模式将自动Send Email任务添加到流程流的末尾，在一个成功的end Event之前。电子邮件任务向请求者发送电子邮件，请求者的电子邮件地址必须作为流程变量显示。电子邮件模板包含用于封装流程结果的流程变量的占位符。
此模式假设通过电子邮件发送的结果完成了案例，并且请求者不需要与创建结果的人进行进一步的交互。然后，该流程不能处理电子邮件结果生成的任何后续问题。
分发列表结果通知
发送标准通知，说明流程已经实现了目标，以便向更广泛的涉众组提供详细信息。例如，“填补职位空缺”流程:当求职者接受工作邀请时，一个案例就成功结束了，在这种情况下，整个公司或部门都能从知道新员工的姓名和入职日期中受益。
业务流程可能与一组固定的涉众相关，他们希望在工作完成时得到通知。此模式自动执行组通知，并有助于提高组织的透明度。
该模式将自动Send Email任务添加到流程流的末尾，在一个成功的end Event之前。电子邮件任务向通讯组列表的固定电子邮件地址发送电子邮件。电子邮件模板包含用于封装流程结果的流程变量的占位符。
这种模式最初提供了过程结果的有限透明度，这可能会在涉众之间设定期望并产生对更多透明度的需求。
这种模式的有用性对案件数量非常敏感:超过一定数量的案件，电子邮件通知就会成为麻烦。但是，这种场景可以产生积极的影响，例如，当一个新的业务或产品组开始时，所有客户订单都有通知，然后庆祝不得不禁用通知作为成功的里程碑。
照片:Snapshooter46/ CC2.0