Business Process Modelling Patterns

In Business Process Management, IT Strategy & Management, Uncategorized by IRM UK0 Comments

Print Friendly

Reusable process model fragments for business users.  The idea of a pattern language, which originates in a 1977 book about buildings and their architecture, translates easily to other kinds of design. This article introduces one kind of pattern language for business process modelling.  A pattern language for architecture uses the idea that certain parts of buildings, or elements of urban planning, are recurring solutions to timeless problems. These patterns create a language that architects can use to talk about their work at a higher level than at the (literal) building blocks of bricks and mortar. As process designers, we can do the same thing for process models. In business process management we use different kinds of patterns to talk about process modelling. These pattern languages differ in their level of abstraction.


Peter Hilton, Signavio, [email protected]

Peter recently spoke at IRM UK’s Business Process Management Conference Europe 2016, 13-16 June London.  Details on the 2017 event can be found here

A Business Process Pattern Language

Low-level workflow patterns

Mentioning ‘patterns’ makes some people immediately think of ‘Workflow Patterns’, with capital letters. Workflow Patterns is an academic project to describe the basic vocabulary of process languages and notations such as BPMN.

If you’re implementing a workflow engine, then Workflow Patterns gives you a useful language for the concepts that you implement on top of a programming language. If you’re a business user then you’d find these patterns too low level to be useful, which is partly why you’re using a graphical modelling and execution in the first place.

Complete business process models

As a business user, you’d probably rather have access to a repository of complete business process models that just happens to contain the exact model that you need, such as a recruitment process, an order to cash process, or something specific to your industry. Unfortunately, you probably won’t find a process repository like this, for various reasons.

  • Companies rarely make details of their business processes public, because they perceive little or no benefit for doing so, because they want to protect their trade secrets, or even because they would be embarrassed if the world knew how they really work.
  • Despite the success of the BPMN 2.0 standard, relatively few people can fluently read and write process models well enough that they would make sense to anyone else and be reusable in practice, even if companies did publish them.
  • Other people’s models have limited usefulness, because it turns out that everyone does things slightly differently. You would probably spend longer understanding and modifying someone else’s model than you would modelling your own process from scratch.

Despite these issues, the world does need a repository of open-source BPMN 2.0 process models that promotes discussion and variations on every model, but that’s a story for another day.

Reusable workflow fragments

If you find that low-level Workflow Patterns are too abstract, and that other people’s complete process models are too specific (or not available), then you might get more value from something in between. You won’t be able to use someone else’s Product Prototype process, but you can reuse the part that represents a document sign-off.

It turns out that complex business processes tend to include model fragments that commonly appear in a number of models. Examples include things like:

  • Document Archive – saving a copy of a document’s final version
  • Multiple Stakeholder Input – getting input on a proposal from multiple stakeholders
  • Rejection Notification – sending a standard notification that an approval has been denied
  • Request Form Approval – management approval for a request entered on a form
  • Separate Complex Work – separating tasks that require specialist expertise.

Most business processes include one or more of these examples, which you’ll find below.

Business process modelling patterns

To avoid confusion with Workflow Patterns (above), let’s call these reusable process model fragments ‘business process modelling patterns’. In keeping with pattern language tradition, each one uses a standard template.

  • Pattern name – a noun phrase that summarises the pattern’s purpose.
  • Process goal – a verb phrase that summarises what the process fragment achieves.
  • Examples – concrete examples of this pattern, as part of real-world processes.
  • Context – when this pattern is useful and when not to use it.
  • Structure – a process model diagram.
  • Participants (a.k.a. collaboration) – how the elements in the diagram work together.
  • Consequences – the trade offs between possible implementation choices.
  • Related patterns – a list of other patterns that do something similar, or participate in a larger structure.

It’s time for some examples, starting with a couple of management approval patterns. Later sections add document patterns, email patterns and collaboration patterns.

Approval Patterns

Management approval is the core of a simple approval workflow, but also often appears as part of a more complex workflow.

Management Approval

The goal of the Management Approval pattern is to capture a decision to approve or reject some kind of proposal or request. Examples of management approvals include employee requests, such as the classic vacation request, document sign-offs for things like contracts, and planning approvals for things like budgets and schedules.

An approval is useful when different people collaborate on a process that separates responsibilities for doing part of the work and confirming that the work is correct. The approval formalises a handover between tasks in a process.

Management Approval has the following structure, as a BPMN 2.0 model.

Peter Hilton1

This structure consists of a decision that is modelled as a user task followed by an exclusive gateway. The purpose of the user task is to capture information – the result of the decision.

One tradeoff to consider is who may perform the Review task. In practice it can be useful  to specify an organisation group as candidates for the task. It may also be desirable add task authorisation, so that only members of the candidate group may complete the task.

Mapping logical roles like Reviewer to organisation users and groups and access control, are process execution considerations that the BPMN model does not show. In practice, when you use a tool like Signavio Workflow to execute the process model, role mappings and access control are part of the process configuration.

Request Form Approval

The goal of a Request Form Approval pattern is to perform Management Approval for data entered earlier on a form, earlier in the same workflow. Examples of form based approvals include employee requests, such as a vacation request or a travel authorisation.

A Request Form Approval works when all of the information about the request can be captured in a single form, so that the information required for the decision is captured as part of the workflow.

This pattern has the following structure, as implemented in a BPMN model.

Peter Hilton2

The structure is the same as for the basic Management Approval, with the addition of an earlier user task to submit the request via a form.

This version of the pattern assumes that a decision to Reject the request cannot be resolved by changing the request. An alternative would be to add a task to change the request so it can be approved, as shown in the next pattern.

Document Patterns

Many workflows handle ‘documents’ – typically word-processor files and spreadsheets, because we commonly use these documents to capture both information and milestones when we collaborate in teams.

Document Approval

The goal of the Document Approval pattern is to perform Management Approval for a document that was produced either as part of the workflow, or as input to the workflow. Examples of document approvals are all kinds of documents that require management sign-off, such as employment contracts and commercial proposals.

Document Approval is a useful way to add an approval milestone to a business by capturing previous work in a document, whose approval confirms that part of a process is complete.

The pattern is a variation on the Management Approval’s structure:

Peter Hilton3

As with the Request Form Approval pattern, Document Approval adds a user task (or trigger form) for uploading the document to be approved. The rejection path is extended with an ‘Update document’ task for correcting the document and trying again. Optionally, the workflow could be extended by adding a ‘Produce document’ task (not shown) to the workflow before this Document Approval.

This version of the Document Approval assumes that correction can always be resolved, or that the case will be abandoned (cancelled) if this is not possible. An alternative would be to split the Reject path into ‘Request revisions’ (not shown) and ‘Reject’.

Document Distribution

The goal of the Document Distribution pattern is to send a copy of the final version of a document by email, to make it available outside the process execution tool. Examples of document archiving include notifying process stakeholders of input to a workflow, such as a CV submitted to a hiring process, or a document created for a task as part of a process, such as a project proposal.

Email is a kind of systems integration, using a document to make information accessible outside the process and system that created it. A document’s context is often a specific workflow milestone, such as the CV that corresponds to a job application milestone, or the sales report that captures an information gathering task’s completion. Email is suitable for ephemeral documents, when no long-term storage is required.

This pattern has the following structure, as implemented in an executable BPMN model.

Peter Hilton4

The key part of the Distribute Document pattern is a Send Task. In a tool like Signavio Workflow, this is a built-in Send email task that automatically sends the document, without human interaction. The other participant is of course the form where the document was uploaded, to add it to the case. The document could also be an email attachment, provided via an email that triggers the process.

A consequence of this pattern is publishing a document outside the scope of its process. Other business processes may come to rely on these documents, creating a dependency between their workflows.

Related patterns: Document Archive can be used the same way.

Document Archive

The goal of the Document Archive pattern is the same as for Document Distribution: to make a copy of the final version of a document available externally. The only difference is the destination: saving the file in Google Drive or Box instead of sending it by email.

Saved files are, like email, a kind of systems integration. For many IT systems, this is the simplest way to exchange information, even if it is not the most sophisticated. File archives are more appropriate when long-term storage is required.

This pattern has the following structure, again using a built-in integration.

Peter Hilton5

The key part of the Archive Document pattern is a built-in automatic Google Drive or Box Upload File task that automatically saves the document. The other participant is the form where the document was uploaded, or the email trigger that provides the file via an email attachment.

A consequence of this pattern is publishing a document outside the scope of its workflow. Other business processes may come to rely on these documents, creating a dependency between their workflows.

Related patterns: Document Distribution can be used the same way.

Collaboration Patterns


The goal of the Consultation pattern is to get input on a draft document from multiple stakeholders. Examples include things like sales reports that require sales data from specific parts of the business or commercial proposals that require feedback from key stakeholders.

Consultation is useful when document preparation requires input from a known list of stakeholders. These stakeholders would normally be defined in terms of roles that relate to the document in question, such as the Project Manager for a project proposal.

This pattern has the following structure, as implemented in a BPMN model. This example shows a proposal that requires feedback from three stakeholders.

Peter Hilton6

The pattern is centred around user tasks for each of the stakeholders who must provide input. These user tasks are surrounded by parallel gateways, to indicate that they will be completed independently, but must all be completed before preparing the next draft of the document can proceed, by consolidating the feedback. The diagram does not show the separate roles defined for each of the stakeholders.

The main trade-off when using this pattern is between the clarity of making the stakeholders explicit, by modelling a user task for each one, and the loss of flexibility in the number of stakeholders. An alternative, when using a tool like Signavio Workflow with case management features, would be to have a single Give Feedback user task, and to create (parallel) ad-hoc subtasks on a case-by-case basis.

The Consultation pattern is related to Document Approval, which can include it as part preparing a draft for review. This is a collaboration workflow pattern as well as a document workflow pattern, so it also relates to other collaboration patterns.

In ad-hoc case management, people assign tasks to each other manually while working on a case. A standardised process may model task assignments using specific users or organisation groups. In some cases, this assignment may be automatic, as in the Timed Escalation pattern.

Timed Escalation

The Timed Escalation pattern reassigns an overdue task to someone, typically a management role, in order to resolve the delay.

A shipping department escalates a ‘Ship order to customer’ task to a manager if the task’s assignee has not shipped the customer’s order within 24 hours, so that the manager can investigate and resolve the delay.

Escalation improves the performance of work performed by a team that includes a supervisor or manager role, and when the manager wants to improve team performance by working on cases that are not handled normally. This contributes to exception-based management.

Peter Hilton7

This is an example from Signavio Workflow, where escalation does have any model structure. Instead, escalation is such a common requirement that Signavio Workflow implements escalation directly as a property of an existing user task. This simplifies the more general BPMN approach of attaching an interrupting timer catch event to the user task and separately modelling the work that escalation adds to the process.

Escalation leads to additional work that the process model omits. In practice, escalation tends to require ad-hoc tasks and a case management approach, rather than pre-defined tasks. This additional work corresponds to ad-hoc sub-tasks – not part of the model, added to the user task whose deadline expired.

Required Role Assignment

The goal of the Required Role Assignment pattern is to make sure that a process role is assigned to someone, and not left unassigned. For example, organising a single big event, such as the office New Year’s party, might require that tasks are evenly distributed among a group of people. Using this pattern makes it possible to use the task list to see that the work isn’t all being done by one person.

More generally, this pattern makes assignment an explicit management task, rather than letting people self-assign work.

This pattern has the following structure, as implemented in a BPMN model.

Peter Hilton8

Even though a user task may be assigned assigned to a logical role, it is not necessarily assigned to a specific person when you execute the process and be completed by any candidate. Assigning a task to a specific user is optional. However, managers may prefer to avoid unassigned tasks so that task deadlines are personal, not collective.

This pattern consists of a single user task for assigning the role, followed by the rest of the workflow that uses the role, by reusing the assignment for later user tasks.

Applying this pattern prevents tasks that are initially unassigned, although an assignment can be removed later. This changes the meaning of the task lists, so that tasks are assigned to people earlier than they would otherwise be.

An important consequence is that assignment does not necessarily mean that work has started on the task, or even intent to complete the task. This makes it harder to spot abandoned tasks, such as when the assignee goes on holiday for two weeks without doing three weeks’ work in the week before leaving.

Separate Complex Work

The goal of the Separate Straightforward Work pattern is to create a path in the workflow so that the majority of the work can be handled by cheaper staff. For example, an IT help desk can typically resolve most calls by following standard procedures, such as creating an email account, while some technical problems require a specialist to investigate.

Separate Complex Work is useful when there is a high volume of cases to be handled by team, where a significant portion of the work can be treated as ‘simple’, and when staff who can handle ‘complex’ work cost significantly more.

This pattern has the following structure, as implemented in a BPMN model.

Peter Hilton9

In this pattern, simple/complex could mean many different things: instead of being complex the work might simply be harder, less defined or more creative than normal, or require a specialist skill.

This pattern splits the underlying process into two variants, and precedes them both with a user task for the decision between them. This introduces additional work to the process, which must be balanced against the cost savings. As well as the cost of the additional work, there may be an additional cost of the delay this introduces. Another potential consequence is that customers with complex cases may experience the initial screening and having the case reassigned as a lower quality of service.

If there are tasks in common between the two variants, the process may join again after the variant part is complete. If the split is repeated, the role assignment can be reused, making the decision automatic instead of manual the second time.

Email Notification Patterns

Using email follows on from collaboration, by adding notifications to various business process participants.

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 BPMN model.

Peter Hilton10

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 BPMN model.

Peter Hilton11

As with the Document Distribution pattern, this 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

This pattern sends 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.

Peter Hilton12

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.


These patterns are just the tip of the iceberg, and are intended more as inspiration to discover your own than as a catalogue you can use directly. In practice, patterns can vary a lot, and useful patterns are likely to capture both organisation-specific and tool-specific solutions to modelling problems. After all, there’s always more than one way to do it.

Peter Hilton is a software developer, writer, speaker, trainer, and musician. He is currently contributing his wealth of experience and knowledge to Signavio through his work on Signavio Workflow , Signavio’s innovative workflow management product.   A programmer and product developer, Peter’s professional interests are Business Process Management, web application development, functional design, agile software development and project management. His software development interests include web application frameworks, software development methodology and practices, and web-based collaboration.   Peter is an engaging presenter and has presented at numerous European developer conferences. Peter co-authored Play for Scala, Manning Publications and is a certified trainer for Fast Track to Play with Scala.

Copyright Peter Hilton, Signavio

Leave a Comment