Email notification patterns

Written by Peter Hilton | 4 min read
Published on: January 7th 2016 - Last modified: November 13th, 2020

Modelling patterns for Signavio Workflow

Email notification patterns capture how a workflow model can include tasks that notify process participants or other stakeholders about a case. These notifications typically include process results or other status updates. This article introduces some collaboration workflow patterns.

This article is part of a series of workflow modelling patterns:

  1. approval patterns
  2. document patterns
  3. collaboration patterns
  4. email patterns.

Rejection Notification

The process goal is to send a standard notification that an approval has been denied, to inform the person who requested the approval. Examples include employee requests, such as a vacation request or a travel authorisation.

For many kinds of requests an immediate automated response has more value than a personal hand-written response that arrives later. Sometimes, the person making a request would prefer to know about a rejection as soon the reviewer has made a decision, especially within an organisation, when the requester does not require any further explanation, or when the reviewer does not have time to respond manually.

This pattern has the following structure, as implemented in a Signavio Workflow process.

Rejection Notification is a variation of a Management Approval pattern that uses an automatic Send Email task to handle a decision to reject the request. This notification task usually, but not necessarily, ends the flow with an End Event.

An automatic notification that ends an approval process might not include enough information to satisfy the person who requested the approval, such when when the notification does not include a reason for the decision. This may create ‘failure demand’ the the process model does not take into account.

Result Notification

The process goal is to send a standard notification that a process has achieved its goal, to provide details to case participants. Examples include procurement requests: a successful travel request for a business trip results in flight booking details (date, airline, flight number, booking reference) that the requesting employee can then use to check in for the flight.

Sometimes, a workflow results in some information that the initiator requires, such as a decision or details of some completed work. This kind of ‘request a response’ process ends when the initiator receives the result. Automating this final step can reduce how long the workflow takes.

This pattern has the following structure, as implemented in a Signavio Workflow process.

The pattern adds an automatic Send Email task to the end of a process’ flow, before a successful End Event. The email task sends an email to the requester, whose email address must be present as a process variable. The email template includes placeholders for the process variables that encapsulate the process result.

This pattern assumes that the emailed result completes the case, and that the requester does not require further interaction with whoever created the result. The process cannot then handle any follow-on questions that the emailed result generates.

Distribution List Result Notification

Send a standard notification that a process has achieved its goal, to provide details to a wider group of stakeholders. Examples include the ‘Fill job vacancy’ process: a case ends successfully when a job applicant has accepted a job offer, in which case the whole company or department benefits from knowing the new employee’s name and start date.

A business process may be related to a fixed group of stakeholders who want to be informed when work is complete. This pattern automates group notification and contributes to organisational transparency.

The pattern adds an automatic Send Email task to the end of a process’ flow, before a successful End Event. The email task sends an email to a distribution list’s fixed email address. The email template includes placeholders for the process variables that encapsulate the process result.

This pattern initially provides limited transparency of process results, which may set expectations and generate demand for more transparency among stakeholders.

This pattern’s usefulness is sensitive to the volume of cases: beyond a certain number of cases, email notifications become a nuisance. However, this scenario can have a positive effect, such as when a new business or product group starts with notifications for all customer orders, and later celebrates having to disable notifications as a success milestone.

Photo: Snapshooter46 / CC BY 2.0

Published on: January 7th 2016 - Last modified: November 13th, 2020