By Peter Hilton
Although we’re used to modelling processes with BPMN, we often talk about recurring ‘patterns’ – frequently used model fragments that capture higher-level concepts than the BPMN activities. This article introduces the Management Approval pattern.
This article is part of a series of workflow modelling patterns:
Management approval is the core of a simple approval workflow, but also often appears as part of a more complex workflow.
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 implemented in a Signavio Workflow process.
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.
In principle, management approval may only be granted by ‘managers’. The Review task would normally have access control configured, so that only members of a specific organisation group can grant approvals.
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.
There are a number of variations on this basic pattern, for more specific workflows.
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 Signavio Workflow process.
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. In Signavio Workflow, you can also model the request as a trigger form.
The Review Request user task has a form that shows the submitted form data using read-only fields, because the data should not be edited at this stage.
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.
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:
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’.