Design Patterns for Approval Processes

Approvals are a common part of today’s business processes. They are oftentimes required by regulations but they also serve to reduce risk in organizations. There are many ways to implement approval processes based on the addressed risk, regulations to be compliant with, required effort, and time added to business processes. This paper presents 14 patterns mined from 180 BPMN processes on GitHub, organizations, and standards, including well-known ones like 4-Eyes Principle but also ones not explicitly defined in literature yet. The result is a pattern language, which covers decisions to be made when designing approval processes and helps to guide process designers, process implementers and regulation bodies to better describe and design approval controls.


INTRODUCTION & MOTIVATION
Approvals are part of many business processes in almost all organizations [14][15][16]29].From holiday approvals for employees to coverage of high-risk decisions, approvals are important to the governance of an organization.However, today's business landscape is changing.Business processes are more and more supported by workflow engines, requiring their formalization.In parallel, regulatory requirements and risk management have led to an increase in necessary safeguards and approvals to stay compliant.Consequently, approval workflows are implemented in many organizations.While necessary from a compliance and/or risk point of view, employees are quickly annoyed by too slow and too complex procedures which hold them back from the work that they are supposed to accomplish.
Thus, balancing the need for security (e.g., risk, compliance) against the costs (e.g., time spent on approval, time lost due to missing approvals, dissatisfaction of employees) arise.Within this paper we present a collection of 14 patterns concerned with the design of approval processes, which can be used to balance different forces like cost, time, and risk.The patterns are organized in five categories to ease and guide their usage.
When designing approval processes, many decisions must be made by process designers based on the risk and the required effort.The presented pattern language captures options for such decisions and offers a way to structure the design process.This is important because approvals serve many purposes.Besides risk reduction they might also shift responsibilities (e.g., doctors are responsible for patients although nurses perform many activities, which thus must be approved by doctors).Bad approvals might (perhaps on purpose) discourage to perform certain business processes if they become too cumbersome and intransparent.
The following stakeholder groups can profit by using these patterns: Process Analysts who design processes together with business representatives, can rely on a pattern language, which allows for easier communication and structured decision making.Software Developers who implement automated business processes, can better understand and possibly re-use templates in their tools, which allows for easier communication and shorter development times.Regulators who require certain approvals, can rely on patterns to better communicate the specification of their requirements.
The remainder of this paper is structured as follows: After presenting related work in the next section, we will explain the mining process in Section 3. Section 4 presents an overview of the patterns found and how they are organized in this paper before Section 5 describes and explains all patterns.To demonstrate the usage and combinations of patterns some examples are presented in Section 6 before the paper concludes and gives an outlook to possible future work.

RELATED WORK
Because public repositories as hosted on GitHub (and previously Sourceforge) allow researchers to access a great number of large repositories easily, some research is concerned with pattern mining such repositories: For example, Surian et al. mined collaboration patterns [25] and Hartel et al. [10] have analyzed EMF models and compiled a list of usage patterns (and error patterns).
The patterns presented in this paper are on a business level, i.e., they are not merely syntactic but each of the patterns will describe desired business behavior.Other existing pattern collections on the business level have been gathered in the "Content" category of patterns identified by a literature survey by Fellmann et al. [7].Related patterns are the "Signature Workflow Patterns" [13], which are concerned with the design of signature workflows.Signatures are similar to approvals and as such there are related and similar patterns betweens Signature Patterns and Approval Patterns.With Artificial Intelligence (AI) being integrated with business processes, there is also a pattern collection of how to integrate AI into business processes modeled in BPMN 1 .

METHODOLOGY
The patterns presented in this paper have been mined by analyzing a collection of BPMN processes on GitHub, which have been extracted from repositories.They have been used in previous studies concerned with BPMN modeling [1,22] (which themselves leveraged on the repository mining done by Heinze et al. [11,12]), projects, and regulatory standards.
A simple Web-based pattern mining tool was developed for classifying the process models as shown in Figure 1.The patterns were mined by following the process shown in Figure 2: The GitHub dataset contains 8925 BPMN models that contain the strings "approv" (catching approve, approval, . . . ) or "verif" (catching verification, verify, . . .).After excluding test models using the same rules like Lübke & Wutke [22] 6262 process models remained.These rules filter for file paths that contain "test" or for process models that are not connected enough, e.g., consisting of many unconnected tasks.As part of manual classification more models were dropped: • 590 process models of the whole GitHub data set have been classified in total, • 167 process models were excluded because the process model language was neither English nor German and thus no evaluation could be done, • 100 process models were excluded because the BPMN.iotooling could not correctly display the diagram, • 3 process models were excluded because the process contained no visible approval, e.g., because signal events were thrown to initiate an approval elsewhere.• 21 process models were excluded because the approval process was contained in a sub-process or call activity.• 84 process models were excluded because they did not contain an approval, • 35 process models were rejected because they did not contain a meaningful approval, e.g., a process consisting only of start and end events, and a single approval step with no distinction of its outcome.
Totally 410 process models were excluded, leaving 180 process models with identified patterns for process mining.

Question Addressed Patterns
Manual Review Intensity (Section 5.

PATTERNS OVERVIEW
According to the Merriam-Webbster dictionary, approving means "to accept as satisfactory" and "to give formal or official sanction" [23, 2a,b].An Approval Process is thus a specialized business process or sub-process in an organization, which aims to check whether a particular action or business process (i.e., the Approval Object) may be executed.For the patterns presented in this paper we assume that all Approvers must approve and no Approval Step may reject the Approval Object (unanimous decision.)

PATTERNS
Within this section we will present the 14 patterns of this pattern language grouped by pattern category.In the given examples we always assume that all Approvers must approve and any rejection leads to the Approval Process outcome to be rejected.

Manual Review Intensity -How many
Approvers are independently in charge of Approval Steps from each other?
Patterns in the Manual Review Intensity category are concerned with the number of Manual Approval Steps which corresponds to the number of involved humans in the Approval Process.Patterns in this category thus share the same context, problem and forces but provide solutions which resolves forces differently.Assignments to Manual Approval Steps can be done directly to a person (e.g., Mrs. Smith has to approve) or to a role (also known as a group).The latter assigns a Manual Approval Step to a set of possible Approvers.Any member of the group can approve or reject.
Care must be taken that Approval Processes are designed with the intend to avoid conflict of interests: If multiple Approvers are to take part, it should be made sure that not one Approver needs to or can approve two or more Approval Steps and also has no conflicts of interest with neither the Approval Object nor the Approval Requester.Also known as Single Approver.

Context
The organization wants to or has to govern the execution of its business process to reduce risks of errors, combat fraud and/or stay compliant with regulatory requirements.

Problem
The organizations needs to decide how many persons must approve the further execution of a business process.

Forces
Regulatory Compliance: In many domains (especially finance and finance-related) many business processes require approvals.These are defined in laws and regulations with regard to appropriate Approval Processes and must be followed by the organizations governed by these.Risk Reduction: Business processes can contain risky operations.Although risk is specific to the organization and can range from "an employee might cheat on vacation application forms" up to "we might lose millions".These risks are to be addressed by appropriate risk countermeasures.Effort for Risk Countermeasures: Risk countermeasures reduce the potential damage from a risk but also impose costs themselves.For example, Manual Approval Steps require effort on part of the approvers.Required Competencies: Approvers require a certain skill set to perform approvals correctly.This includes the domain knowledge for approving something as well as the knowledge about the Approval Process.Available Resources: Approvers must be available and the organization must ensure that also in case of vacations and sickness leave, Manual Approval Steps are performed by substitutes.The larger an organization is, the easier it is to have multiple people with the required competencies.Process Execution Time: By adding Manual Approval Steps the business process will take longer to complete.The added time not only consists of real working time but also of waiting time, i.e., the Manual Approval Step is ready to be done but no Approver has started working on it yet.By adding more Manual Approval Steps the delay in process execution usually increases and reduces efficiency in the organization as well as acceptance by Approval Requesters.

Solution
Designate a role or person that has to approve the requested business process.
As shown in Figure 4 this pattern introduces a single Manual Approval Step before the main part of the business process is performed.The Approver may approve the request or reject it.The latter is not shown in the process diagram because this aspect will be addressed by patterns in the Correction Strategy category later.
A single person or preferably a role, i.e., a group of people, can approve a request.With a group of people, redundancy is introduced that improves approval times and availability, e.g., in case of illness or vacations, and thus improves overall process execution times.
The organization must instruct Approvers what parts of the request they need to check and what business rules apply and lead to the approval or rejection outcome, e.g., by using checklists.

Consequences
Regulatory Compliance: This pattern satisfies regulatory compliance, if applicable regulations do not require approvals by more people.Risk Reduction: While this pattern will reduce risks, having only one person to look at an approval opens the chance for higher error rates, especially if multiple competencies are required or the underlying business rules of an approval are very complex.Effort for Risk Countermeasures: By having only one person approve the decision, this pattern is lightweight and does not require much effort -although the actual effort is dependent on the business rules for the approval.Required Competencies: This pattern is only suitable if one person has all the competencies required to make the approval decision.If business rules require too much domain knowledge, a single approver might not be competent enough.Available Resources: Because only one person must approve, this type of approval is well suited for smaller organizations in which not many people are available.Also not many people are involved and thus have to spend time for approvals and respective training.Process Execution Time: In contrast to approvals involving multiple approvers the process execution time is only influenced by the availability of one approver.

Related Patterns
If regulations require more approvers or the organization wants to further reduce risks, one of the 4-or 6-Eyes Principle patterns might be a more suitable option.
If some or all business rule logic can be automated and the approval is re-occurring often, it might be worthwhile to either add a Pre-Check Rule or even switch to a Fully Automated Approval Step.

Known Uses
• 104 processes in the GitHub dataset have been identified to use the 2-Eyes Principle.• Tools like ProcessMaker2 support the 2-Eyes Principle pattern.

Context
The organization wants to or has to govern the execution of its business process to reduce risks of errors, combat fraud and/or stay compliant with regulatory requirements.

Problem
The organizations needs to decide how many persons must approve the further execution of a business process.

Forces
Regulatory Compliance: In many domains (especially finance and finance-related) many business processes require approvals.These are defined in laws and regulations with regard to appropriate Approval Processes and must be followed by the organizations governed by these.Risk Reduction: Business processes can contain risky operations.Although risk is specific to the organization and can range from "an employee might cheat on vacation application forms" up to "we might lose millions".These risks are to be addressed by appropriate risk countermeasures.Effort for Risk Countermeasures: Risk countermeasures reduce the potential damage from a risk but also impose costs themselves.For example, Manual Approval Steps require effort on part of the approvers.Required Competencies: Approvers require a certain skill set to perform approvals correctly.This includes the domain knowledge for approving something as well as the knowledge about the Approval Process.Available Resources: Approvers must be available and the organization must ensure that also in case of vacations and sickness leave, Manual Approval Steps are performed by substitutes.The larger an organization is, the easier it is to have multiple people with the required competencies.Process Execution Time: By adding Manual Approval Steps the business process will take longer to complete.The added time not only consists of real working time but also of waiting time, i.e., the Manual Approval Step is ready to be done but no Approver has started working on it yet.By adding more Manual Approval Steps the delay in process execution usually increases and reduces efficiency in the organization as well as acceptance by Approval Requesters.

Solution
Require that two distinct persons of your organizations approve the requested business process.
As shown in Figure 5 this pattern introduces two Manual Approval Steps by two distinct people before the main part of the business process is performed.Both Approvers must approve the request before the process may continue.The Manual Approval Steps can be executed sequentially (as shown in this figure, using the Sequential Approval pattern) or parallel (using the Parallel Approval Pattern).The rejection of an approval is not shown in the process diagram because this aspect will be addressed by patterns in the Correction Strategy category.
The organization must instruct Approvers what parts of the request they need to check and what business rules apply and lead to the approval or rejection outcome, e.g., by using checklists.

Consequences
Regulatory Compliance: This pattern satisfies regulatory compliance, if applicable regulations do not require approvals by more than two people.By having more than one approver, this pattern satisfies Segregation of Duties [26] requirements.Risk Reduction: This pattern reduces risks by preventing many approval errors by having different approvers.Effort for Risk Countermeasures: By having two people approve the decision, this approval pattern is more heavyweight than the "2-Eyes Principle" and requires more effortalthough the actual effort is dependent on the business rules for the approval.Required Competencies: This pattern can be used to split different approval aspects to people with different competencies, thereby covering certain aspects with more experienced people.Available Resources: Because two people must approve a request, this type of approval requires more availability of approvers than the "2-Eyes Principle".This also affects substition in case of Approvers have days off or are sick or not working for other reasons.Process Execution Time: Process execution time is negatively influenced by the availability of both Approvers.If regulations require more approvers or the organization wants to further reduce risks, the 6-Eyes Principle pattern might be a more suitable option.If less rigorous control is required, an organization might consider using the "2-Eyes Principle".
If some or all business rule logic can be automated and the approval is re-occurring often, it might be worthwhile to either add a Pre-Check Rule or even switch to a Fully Automated Approval Step.

Known Uses
• 33 processes in the GitHub dataset have been identified to use the 4-Eyes Principle.• Financial institutions are required by law to use 4-Eyes Principle approvals as identified by Delfmann & Hüber [5] in their pattern catalogue for business process compliance in the financial sector.• Terravis [2] uses this pattern for Trustee-related processes: All applications to land registries are required to be signed off by two different Approvers.• The European Quality Guidelines on Frames for Social Statistics3 require 4-Eyes Principle for certain approvals.• Evonic has internal rules 4 for applying the four-eyes principle in its organizational processes.• ING offers 4-Eyes principal approvals of payment transactions for business accounts 5 .• Tools like ProcessMaker6 support the 4-Eyes principle pattern.• Fragmento, a research project offering library of process fragments, uses the 4-Eyes Principle as an example [24].Also, the research project AMABULO uses the 4-Eyes Principle as an example [4].• Kumar et al. [18] identified that in the medical domain, more precisely areas "that have high adverse event probabilities", checklists are to be followed by two nurses to combat negligence.
• Many scientific conferences and journals conduct a peerreview based on two reviewers (which map to Approvers in our domain model.) 5.1.3Pattern: 6-Eyes Principle.
The 6-Eyes Principle adds another Approver on top of the 4-Eyes Principle thereby strengthening and weakening the corresponding forces even further.
However, process designers should observe that adding more and more Approvers will not indefinitely improve the quality of the approvals.If approvals are merely "rubber stamped" because people do not know what to check, why to check or have no knowledge to contribute, effort is spent without additional benefit.This can lead to several process weaknesses [6] in the Approval Process.
In principle, additional Approvers can be added, thereby employing an n-Eyes Principle.However, only the 2 to 6-Eyes Principles have been commonly named this way in literature.

Related Patterns
If regulations require less approvers or the organization wants to reduce costs for risk countermeasures, one of the 2-or 4-Eyes Principle patterns might be a more suitable option.
If some or all business rule logic can be automated and the approval is re-occurring often, it might be worthwhile to either add a Pre-Check Rule or even switch to a Fully Automated Approval Step.
Different approvers can work in a Sequential Approval or a Parallel Approval.In contrast to the 2-Eyes or 4-Eyes-Principle patterns, Sequential and Parallel Approvals can be combined, e.g., having one Approval Step followed by two parallel Approval Steps.

Known Uses
• 10 processes in the GitHub dataset have been identified to use the 6-Eyes Principle.• Tools like ProcessMaker7 support the 6-Eyes Principle pattern.
• Spiffworkflow has an article featuring how to implement the 6-Eyes Principle in conjunction with the Parallel Approval pattern in their workflow engine 8 .

Context
The organization wants to or has to govern the execution of its business process to reduce risks of errors, combat fraud and/or stay compliant with regulatory requirements.

Problem
The organizations needs to decide how many persons must approve the further execution of a business process based on run-time properties of the Approval Process like risk, financial impact or the Approval Requester.

Forces
Potential Risk: An approval is performed to address a risk with a certain probability and damage.An approval should address the risk with economical suitable countermeasures.
If the risk varies a lot, e.g., because in an order process the total order amount varies greatly, the approvals should be adjusted as well.Regulatory Compliance: In many domains (especially finance and finance-related) many business processes require approvals.These are defined in laws and regulations with regard to appropriate Approval Processes and must be followed by the organizations governed by these.Risk Reduction: Business processes can contain risky operations.Although risk is specific to the organization and can range from "an employee might cheat on vacation application forms" up to "we might lose millions".These risks are to be addressed by appropriate risk countermeasures.Effort for Risk Countermeasures: Risk countermeasures reduce the potential damage from a risk but also impose costs themselves.For example, Manual Approval Steps require effort on part of the approvers.Required Competencies: Approvers require a certain skill set to perform approvals correctly.This includes the domain knowledge for approving something as well as the knowledge about the Approval Process.Available Resources: Approvers must be available and the organization must ensure that also in case of vacations and sickness leave, Manual Approval Steps are performed by substitutes.The larger an organization is, the easier it is to have multiple people with the required competencies.Process Execution Time: By adding Manual Approval Steps the business process will take longer to complete.The added time not only consists of real working time but also of waiting time, i.e., the Manual Approval Step is ready to be done As shown in Figure 6 this pattern evaluates how many approvers and thus manual approval steps are required at run-time and thus can dynamically change the intensity of the approval, e.g., depending on the Approval Object or the Approval Requester.
Figure 7 shows another structural variant, in which the first approval step is always executed and a check is made whether a second approval step is required.
The organization must define the governing business rules, which are used to make the configuration decision at run-time.

Related Patterns
The result of the evaluation may be that a 2-, 4-or 6-Eyes Principle is used.
If two or more Approvers are selected, the decision on whether to use Sequential Approval and/or Parallel Approval must be made.
The business rule covering the configuration of an approval may be automated by using the Approval Steps Configuration Rule pattern.
The "Dynamic Countersignature Pattern" [13] also describes a dynamic selection of Approvers (in a signature process).However, the selection in this related pattern is done by the initiator while in this pattern the selection is decided by the organization (in the form of standardized business rules).

Involved Roles -What different competencies of Approvers are required in Approvals?
If two or more Approvers are selected, the patterns in the Involved Roles category are concerned with how these different Approvers can be selected.
In general, organizations can decide to widen or deepen the competencies in an Approval: By adding Approvers with different compentencies, a wider range of mistakes and problems might be spotted.By adding people with same compentencies, deeper knowledge of a particular kind is accumulated leading to a higher likelihood of finding a specific type of mistake or problem.Competencies in these patterns are broadly defined: An Approver might have certain skills and/or experience and/or a certain position in organization that qualify to perform an Approval Step.
These patterns do not address regulatory requirements.For example, some approvals may only be done by certified people like notaries, accountants or people having other, official certifications.

Context
An organization has risks associated with a business process that warrant two ore more Approvers in the corresponding Approval Process.

Problem
The organization wants to conduct a more thorough review in Manual Approval Steps.

Forces
Individuals' Errors: Approvers can make errors and the more complex the approval is to conduct, the more likely errors are made, which the organization wanted to catch.Number of Competencies required: Some approvals are very narrow in the required competencies, e.g., approving holidays, while others require more knowledge and possibly knowledge in different fields, e.g., checking house construction plans.

Solution
Designate multiple Approvers with the same skill set, e.g., same role, to approve in an Approval Process.The organization must take care that this role has all competencies required for conducting the approval.

Consequences
Individuals' Errors: Because two or more Approvers check the same aspects in the Approval Object, mistakes by previous Approvers can be spotted.For example, when two controllers check an invoice., the first Approver might miss an error, which the second is hopefully able to find.Number of Competencies required: Each Approver must have all required competencies.This is more likely to be achievable if the required competencies are very specific.

Related Patterns
The More of the Same pattern can be used in conjunction with the 4-and 6-Eyes Principle patterns.
The ordering of the Manual Approval Steps of Approvers with the same skill set can be defined by using the Sequential Approval or the Parallel Approval patterns.
Together with at least 3 Approvers (e.g., using the 6-Eyes Principle pattern), this pattern can be combined with the More of the Same pattern to offer redundancy only for specific approval aspects.For example, one aspect might be checked by two approvers while another aspect is checked by another approver with a different skill set.

Known Uses
• 3 processes in the GitHub dataset have been identified to use this pattern.
• Terravis [20] uses the More of the Same pattern with its 4and 6-Eyes Approvals: There is only one Approver role, which is not further broken down.This role is assigned to bank employees, which are then eligible candidates in Manual Approval Steps.

Context
An organization has risks associated with a business process that warrant two or more Approvers in the corresponding Approval Process.

Problem
The required competencies, e.g., knowledge in different domains, is too broad to be covered by a single Approver.

Forces
Individuals' Errors: Approvers can make errors and the more complex the approval is to conduct, the more likely errors are made, which the organization wanted to catch.Number of Competencies required: Some approvals are very narrow in the required competencies, e.g., approving holidays, while others require more knowledge and possibly knowledge in different fields, e.g., checking house construction plans.

Solution
Designate multiple Approvers with different skill sets, e.g., different roles, to approve in Approval process.
As shown in Figure 9 this pattern has multiple (in the sketch two) different Manual Approval Steps which are executed by people in different roles.The assumption is that their respective specialized skill set will enable them to check different aspects of the approval.
The organization must take care that all roles together have all competencies required for conducting the approval, and that each role knows for which aspect of the Approval Object and the Approval Requester it is responsible.For example, one competency might be to decide whether the first Approver was allowed to approve an Approval Request.

Related Patterns
The Different Competencies pattern can be used in conjunction with the 4-and 6-Eyes Principle patterns.
Together with at least 3 Approvers (e.g., using the 6-Eyes Principle pattern), this pattern can be combined with the More of the Same pattern to offer redundancy for specific aspects of the Approval Object.For example, one aspect might be checked by two Approvers while another aspect is checked by another approver with a different skill set.
The ordering of the Manual Approval Steps of approvers with different skill sets can be defined by using the Sequential Approval or the Parallel Approval patterns.

Known Uses
• 23 processes in the GitHub dataset have been identified to use this pattern.

Business Rule Usage -What parts of the Approval Process are governed by automated business rules?
Human decisions in general and approvals in particular are in general time-consuming and thus expensive.Patterns in the Business Rule Usage category are concerned with the use of automated business rules in an Approval Process to optimize different aspects in process execution.

Context
An organization has defined an Approval Process containing at least a partly automatable Approval Steps.

Problem
The organization wants to reduce process cycle times and process costs by reducing the work performed in Manual Approval Steps.

Forces
Process Cycle Times: Approvals negatively impact the cycle time of business processes within an organization because they do not add immediate business value to the desired process outcome.As such, Approval Processes should be performed as quickly as possible.
Process Costs: Approvals add to the process costs.Especially, Manual Approval Steps add costs due to employees operating the processes.Implementation Costs: Setting up automated business rules in software systems results in upfront costs.The more complex the automation is, the more expensive it is.Ability to Automate: Data and rules in Approval Steps need to be structured in a way that they can be automated.

Solution
Add an automated business rule as the first Approval Step, which performs some automated checks prior to any Manual Approval Step in order to reduce effort of approvals.
As shown in Figure 10 this pattern introduces an automated business rule prior to Manual Approval Step(s), which can automatically perform some checks.The checks performed by the Pre-Check Rule are not performed again by the Approver.The automated checks can be some low hanging fruits whereby automation is used for easy tasks (e.g., does the Approval Requester is allowed to place such a request?) and thereby freeing the Approvers from tedious tasks.Hard to automate parts are still performed by the Approvers.

Consequences
Process Cycle Times: The Approval Process is completed quicker by automating part of the decision and thereby relieving employees from probably "dumb" tasks .Process Costs: The costs for performing an Approval Process instance is usually lower than a manual approval by automating part of the decision and thereby reducing time spent on Manual Approval Steps.Implementation Costs: This pattern is easier and cheaper to implement than full automation because only those parts of the decision are automated, which can be automated efficiently.Ability to Automate: Implementations of this pattern can deal with decisions that are partly automatable and partly very hard or impossible to automate by delegating parts of the decision to humans.

Related Patterns
The Pre-Check Rule must be used in conjunction with Manual Review Steps, which, e.g., can be introduced by using the 2-, 4-, and 6-Eyes Principle pattern.
The Pre-Check Rule and the following Manual Review Step(s) are executed sequentially, i.e., by using the Sequential Approval pattern.

Known Uses
• 18 processes in the GitHub dataset have been identified to use this pattern.

Context
An organization has defined an Approval Process, which contains Manual Approval Steps that are selected, e.g., by using the Dynamic Approvers pattern.

Problem
The organization wants to reduce process cycle times and process costs by reducing necessary work to evaluate which Approvers should be part in a given Approval Process.

Forces
Process Cycle Times: Approvals negatively impact the cycle time of business processes within an organization because they do not add immediate business value to the desired process outcome.As such, Approval Processes should be performed as quickly as possible.Process Costs: Approvals add to the process costs.Especially, Manual Approval Steps add costs due to employees operating the processes.Implementation Costs: Setting up automated business rules in software systems results in upfront costs.The more complex the automation is, the more expensive it is.Ability to Automate: Data and rules in Approval Steps need to be structured in a way that they can be automated.

Solution
Add an automated business rule, which decides which Manual Approval Steps are best for the given Approval.
As shown in Figure 11 this pattern introduces a business rule prior to Manual Approval Steps.The rule evaluates which and how many Approvers will participate in an Approval Process.
The rule may scale the number of different Approvers (including more competencies) and/or the number of Approvers with same competencies.For example, the rule might select two accountants instead of one if there are more than 50 positions on an invoice, and may additionally select the accountants' team lead if the invoice amount exceeds 100,000€.
Organizations must adjust the configuration rule to strike a balance between effort (costs and time) and covered risk.In special cases this may lead to a rule not assigning any Approver if the risk is deemed small enough.

Pattern: Fully Automated Approval
Step.

Context
An organization has defined an Approval Process containing automatable Approval Steps.

Problem
The organization wants to reduce process cycle times and process costs by reducing the work performed in Manual Approval Steps.

Forces
Process Cycle Times: Approvals negatively impact the cycle time of business processes within an organization because they do not add immediate business value to the desired process outcome.As such, Approval Processes should be performed as quickly as possible.Process Costs: Approvals add to the process costs.Especially, Manual Approval Steps add costs due to employees operating the processes.Implementation Costs: Setting up automated business rules in software systems results in upfront costs.The more complex the automation is, the more expensive it is.Ability to Automate: Data and rules in Approval Steps need to be structured in a way that they can be automated.

Solution
Add an automated approval step, e.g., a business rule, which decides the overall Approval Outcome.
As shown in Figure 12 this pattern introduces an automated approval step, here a business rule task, which is an automated task and decides the Approval Outcome.

Related Patterns
The Approval Steps Configuration Rule pattern can be combined with this pattern to offer a third Approval Step outcome: If the Fully Automated Approval Step rule cannot make a confident decision, the decision is delegated to a manual approval dynamically configured by the same business rule.

Known Uses
• 16 processes in the GitHub dataset have been identified to use this pattern.• Terravis [2] uses the Fully Automated Business Rule pattern to cover approvals of mortgage note transfers between banks, e.g., if a bank initiates a transfer of a mortgage letter managed by Terravis, it is automatically checked whether the mortgage letter is with the bank and not locked for transfer.• A Swiss financial institute uses the Fully Automated Approval Step pattern in conjunction with the Approval Steps Configuration Rule pattern to automatically process customer applications.In case of rules nearing their threshold values (e.g., the financial scoring of the applicant is not good but not necessarily too bad either) it delegates the decision to a bank employee.

Execution Order -In which order should multiple Approval Steps be executed?
Manual and automated Approval Steps need to be ordered for execution.Thus, patterns in the Execution Order category are concerned with the ordering and parallelization of Approval Steps.

Problem
The organization must decide how and in which order to perform all Approval Steps in the Approval Process.

Forces
Resource Usage/Process Costs: Resources like employees or computing power are used in an Approval Process.Costs are associated with their use so organizations want to minimize them.Process Cycle Time: Approval Processes cost time before the desired action can be started.These delays implicate opportunity costs.As such, organizations want to speed up Approval Processes as much as possible.

Solution
Sequentially execute all Approval Steps.As shown in Figure 13 this pattern orders Approval Steps in a sequence.Only after one step is completed, e.g., a business rule executed or a Manual Approval Step is completed, the process will move to the next Approval Step.
Because Approval Steps are executed sequentially, it is possible that following Approval Steps take into account information from previous Approval Steps.For improving process cycle time and reducing process costs in case of rejections further, sequential Approval Steps should be sorted carefully.For example, ordering medical examinations by different specialists by the probability of finding the patient unfit for surgery have been shown to improve the overall process [17].From a more theoretical point of view, Garey [9] developed a mathematical model for the "Filter Ordering Problem" to represent the ordering of tasks as an optimization problem.Later, van der Aalst [27] provided a different model together with a simulation and heuristics to design what he calls knock-out processes, i.e, processes that like Approval Processes are completed when any step results in a negative outcome.

Related Patterns
This pattern is an implementation of the "Sequence" workflow pattern [28].
When there are more than two Approval Steps in an Approval Process (e.g., 6-Eyes Principle or 4-Eyes Principle combined with Fully Automated Approval Step), this pattern may be combined with the Parallel Approval pattern.
The "Sequential Signature Pattern" [13] describes a similar pattern in which documents are signed sequentially.

Known Uses
• 71 processes in the GitHub dataset have been identified to use the Sequential Approval pattern.• Terravis [2] uses this approval type for all approvals.For example, all approvals done by banks or the trustee employees are executed sequentially.• Medical examinations for checking the preconditions of planned treatments are mostly sequential because they depend on the patient to be present [17].

Context
An organization has chosen to use more than one Approval Step in an Approval Process and at least two Approval Steps can be performed independently of each other.

Problem
The organization must decide how and in which order to perform all Approval Steps in the Approval Process.

Forces
Resource Usage/Process Costs: Resources like employees or computing power are used in an Approval Process.Costs are associated with their use so organizations want to minimize them.Process Cycle Time: Approval Processes cost time before the desired action can be started.These delays implicate opportunity costs.As such, organizations want to speed up Approval Processes as much as possible.

Solution
Execute Approval Steps, which can be performed independently, in parallel.
As shown in Figure 14 this pattern executes Approval Steps in a parallel manner.
The Approval Process is completed whenever all Approval Steps have been successfully completed or any Approval Step has finally declined approval.For improving process costs, it is sensible that all unfinished Approval Steps are aborted if the approval is finally declined as for example shown in the example in Section 6.2.However, without software system support, aborting parallel approvals might be an organizational challenge.

Related Patterns
This pattern is an implementation of the "Parallel Split" workflow pattern [28].
When there are more than two Approval Steps in an Approval Process (e.g., 6-Eyes Principle or 4-Eyes Principle combined with Fully Automated Approval Step), this pattern may be combined with the Sequential Approval pattern.
The "Static Countersignature Pattern" [13] describes a parallel signature process similar to parallel Approval Processes, which additionally is defined by a static set of Approvers.

Known Uses
• 9 processes in the GitHub dataset have been identified to use the Parallel Approval pattern.• Spiffworkflow has an article on how to implement the Parallel Approval pattern in their workflow engine 9 .
9 https://www.spiffworkflow.org/posts/deep_dives/approval/If an Approval Requester has the possibility to correct or improve the Approval Object, the re-check within the Approval Process is modeled by repeating the same task in the following examples.In practice, only portions of the Approval Object need to be rechecked -depending on the changes.This allows the re-check to be performed quicker than the first check.However, Approvers require support to easily spot the changes and know which re-checks must be made.

Context
An organization has is defining an Approval Process.

Problem
The organization must define what happens if one of the Approval Steps rejects an approval.

Forces
Possibility to Cure: An approval might be done for an object that is immutable.For example, customer properties like being contained in a sanctions list is neither influenced by the Approval Requester nor by the Approver.As such, corrections might be impossible.Effort by Approval Requester: If a curable defect is detected, the Approval Requester may correct it.Different options to correct or restart this defect influence how much effort is required by the Approval Requester.Effort in Approval Process: If a curable defect is detected, the point on where a correction re-triggers approval steps influences the effort required by the repeated Approval Steps.

Solution
Ultimately reject the approval after the rejecting Approval Step and offer no possibility to re-work or to correct the deficiencies.
As shown in Figure 15 this pattern will stop the Approval Process -commonly with a notification to the Approval Requester -and offer no possibility to cure the deficiency or to restart the Approval Process.

Related Patterns
The decision which pattern in the Correction Strategy to use can be made for each Approval Step.This means that this pattern can co-exist with all other patterns in this category in an Approval Process.
An organization may allow the Approver or a Fully Automated Approval Step to decide whether to Reject Ultimately or to allow to correct deficiencies.
A Pre-Check Rule can Reject Ultimately.

Known Uses
• 130 processes in the GitHub dataset have been identified to use the Reject Ultimately pattern.• Terravis [2] uses this pattern for approvals by notaries: If a notary does not certify a business, the whole business process is cancelled.
• A Swiss financial institute uses the Reject Ultimately pattern, if the applicant for a credit card does not meet minimum criteria or is listed on a sanctions list.

Context
An organization is defining an Approval Process, which consists of two or more Approval Stepsand in which problems with the Approval Object might be correctable.

Problem
The organization must define what happens if one of the Approval Steps rejects an approval.

Forces
Possibility to Cure: An approval might be done for an object that is immutable.For example, customer properties like being contained in a sanctions list is neither influenced by the Approval Requester nor by the Approver.As such, corrections might be impossible.
Effort by Approval Requester: If a curable defect is detected, the Approval Requester may correct it.Different options to correct or restart this defect influence how much effort is required by the Approval Requester.Effort in Approval Process: If a curable defect is detected, the point on where a correction re-triggers approval steps influences the effort required by the repeated Approval Steps.

Solution
Allow the Approval Requester to correct findingss and proceed the Approval Process by starting over with the first Approval Step.
As shown in Figure 16 this pattern will allow the Approval Requester to make corrections to the Approval Object and restart the process.This means that although "Approval Step 2" in the solution sketch failed, "Approval Step 1" is executed again.
Repeated executions of Approval Steps are slightly different from their first executions: Approvers already know the Approval Object to a certain extend and might only review the changes between the last and the newest version of an Approval Object.

Related Patterns
The decision which pattern in the Correction Strategy to use can be made for each Approval Step.This means that this pattern can co-exist with all other patterns in this category in an Approval Process.
An organization may allow the Approver or a Fully Automated Approval Step to decide which pattern of the Correction Strategy to apply.

Known Uses
• 35 processes in the GitHub dataset have been identified to use the Correct & Restart Process pattern.• Terravis [2] requires processes started by banks to be restarted again if other bank employees reject the approval.

Context
An organization is defining an Approval Process, which consists of two or more Approval Stepsand in which problems with the Approval Object might be correctable.

Problem
The

Related Patterns
The decision which pattern in the Correction Strategy to use can be made for each Approval Step.This means that this pattern can co-exist with all other patterns in this category in an Approval Process.
An organization may allow the Approver or a Fully Automated Approval Step to decide whether to Reject Ultimately or to allow some correction.
The use of the Multiple Competencies pattern will increase the probability for violating review consistency.
To strictly differentiate patterns, this pattern cannot be used with an Approval Process consisting of one Approval Step (e.g.The "Return Signature Pattern" [13] is a more generalized pattern in the context of signature processes.While the return point in this pattern might be any point previously executed in a process, this pattern explicitly corrects and repeats one Approval Step.

EXAMPLES
Within this section example Approval Processes and one process of the GitHub data set are presented to demonstrate the usage of the presented patterns and to illustrate their combined use.

Bank Account Creation
The "Bank Account Creation" process as illustrated in Figure 18 aims to process an application by a bank prospect or customer and is performed as follows: A person wants to create a new account with a bank.All passed information is checked by a Pre-Check Rule for consistency, completeness, whether the person is on a sanction list etc.If the provided information is inconsistent or any check cannot be made automatically, the case is delegated to a call center agent, which is an implementation of the Dynamic Approvers pattern.In this case the business rule also serves as a Approval Steps Configuration Rule.All steps are performed as a Sequential Approval.In case of a decline the customer is offered no possibility to correct findings by using the Reject Ultimately pattern.

Purchase Request
The "Purchase Request" process as shown in Figure 19   The "New Note" Process as found on GitHub 10 (and redrawn for better image quality) is shown in Figure 20.This process was classified as part of the pattern mining process and four patterns were found.This is an executable process, which has Script Tasks for implementing internal logic (and probably data persistence).From a business point of view, a Business Rule Task implements the Approval Step Configuration Rule pattern.Depending on the rule outcome, a 2-Eyes Principle approval is initiated or the request is approved as-is.Finally, a Call Activity is used to call another process to implement further steps.The "Blockchain Registration Process" is also found on GitHub 11 .It shows that processes, which are not following BPMN best practices (e.g., labeling tasks with verb+object, labeling conditions on sequence flows originating from gateways or using gateways instead of conditional sequence flows) are more difficult to understand and thus also take more time to classify.In this process a request is submitted, which is afterwards approved in parallel by both the Operations as well as the Marketing.It seems that each of these parties can demand the revision of the request.If not, a third party might be invovled for a review, which can again result in revision or approval.Upon revision, the Approver Requester can cancel its request or proceed with submitting it again.

CONCLUSIONS & OUTLOOK
This paper has presented a pattern language helping to design approval processes.The pattern language consists of 5 categories and is suited to guide process designers to consciously decide on possible solutions.
This pattern language does not address how to create rule sets which are used in Approval Steps, e.g., review checklists.Oftentimes organizations will not have explicitly defined their rules but instead qualified people will check based on their experience or education.Automated and thus formalizing these rules is a task that requires much effort.Machine learning (ML) and other technologies might help: By training ML models with past user decisions might be an interesting research venue.However, like with all ML work, problems like bias [3] must be taken care of.
For improving the usefulness and usability of this pattern language, future research could implement the patterns into existing process modeling tools.Such tool support could either guide the process designer by an internal decision tree or offer process fragments and skeletons, which can be incorporated into process models.Such an approach reduces development time when automating business processes, e.g., by adding this tooling into a modeler for executable BPMN.This could be accomplished by using reusable fragments.Feasible approaches for accomplishing such a composition have been presented by Schumm et al. [24] and Laue & Kirchner [19].However, as a prerequisite is research into optimal BPMN modeling of the different patterns because BPMN is powerful but offers many possibilities to reach the same semantics.One question, for example, is how Approval Processes can be modeled, e.g., by prepending the Approval Steps activities before the main acitvities or by using subprocesses or call activities.
In general, empirical research of process models with public repositories would benefit by having more metadata about process models available.For example, one could evaluate which patterns are more common in which domains.A template for such metadata exists [21] but is not in widespread use yet.
The pattern language can be extended with patterns for aggregating the individual results of Approval Steps: With the current set of patterns presented in this paper all Approvers must approve but it could also be, for example, a majority vote.Also, pattern mining with regard to escalations in case of Approvers do not react timely.
Overall, this paper presented the first set of patterns for designing Approval Processes and are the foundation for further research while already offering help for process designers.

Figure 1 :
Figure 1: The Web Application Used for Manually Mining Approval Patterns

Figure 2 :
Figure 2: Pattern Mining Process for Approval Patterns in the GitHub Process Collection

Figure 3 :
Figure 3: Domain Model and Pattern Relations

Figure 8 :
Figure 8: Solution Sketch for More of the Same (without approval rejection)

Figure 9 :
Figure 9: Solution Sketch for Different Competencies (without approval rejection)

Process
Cycle Times: By dynamically sizing the Approval Process, low-risk approvals can be performed quicker compared to a one-size-fits-all solution.Process Costs: By dynamically sizing the Approval Process, low-risk approvals can be performed cheaper compared to a one-size-fits-all solution.Implementation Costs: Configuration Rules can be implemented easily and are a low-threshold investment.Ability to Automate: No part of the Approval Process itself is automated.Related PatternsAn implementation of the Approval Steps Configuration Rule pattern can select one of the 2-, 4-, and 6-Eyes Principle patterns based on the to-be-covered risk.

Figure 10 :Figure 11 :
Figure 10: Solution Sketch for Pre-Check Rule (without approval rejection) Process Cycle Times: Automatic Approval Steps are usually performed much faster and will eliminate overhead time introduced by the Approval Process for most practical purposes.Process Costs: Automated Approval Steps are usually performed cheaper than Manual Approval Steps thereby reducing process costs.Implementation Costs: Automated Business Rules require a high-quality implementation and careful testing.Implementation costs are higher than for other business rule patterns in this category.Additionally, organizations must carefully implement (and test) the automated rule.Because no human intervention occurs later, possible mistakes and errors might not be spotted.Ability to Automate: The Approval needs to be fully automatable.Technical complexity might be introduced to fully automate the decision.

5. 4 . 1
Pattern: Sequential Approval.ContextAn organization has chosen to use more than one Approval Step in an Approval Process.

Figure 12 :Figure 13 :
Figure 12: Solution Sketch for Fully Automated Approval Step (without approval rejection)
Resource Usage/Process Costs: Resources spent on approvals in case of rejections are larger than with sequential Approval Steps because all Approvers and rules are working in parallel.Process Cycle Time: Because Approval Steps are executed in parallel, the cycle time of an Approval Process is only the time it takes for the longest Approval Step to complete.

, using 2 -
Eyes Principle or Fully Automated Approval Step exclusively).The solution would be indistinguishable from the application of the Correct & Restart Process pattern, and Correct & Restart Process is the semantically better matching name.

•
19 processes in the GitHub dataset have been identified to use the Correct & Repeat Step pattern.• A Swiss financial institute uses the Correct & Repeat Step pattern, if the applicant for a credit card has not submitted all required evidence, like ID, and offers to send those missing documents.

Figure 18 :
Figure 18: Approval Process for Bank Account Creation

Figure 19 :
Figure 19: Approval Process for Purchase Request is used by employees to order products they need for their work.Depending on the total price of the order, a Configuration Rule assigns Dynamic Approvers by requesting an approval of only the team lead or also the department lead.Due to the different roles, the process implements the Different Competencies pattern.Both Manual Approval Steps are implemented as a Parallel Approval.After being notified of a pending Approval Request each Approver can decide whether the request is approved, rejected or rework is required.This is illustrated in the sub-process at the bottom of Figure19.In case of rework, the Correct & Restart pattern is used to allow the Approval Requester to make corrections to the original request and start the Approval Process all over again.

Table 1 :
Pattern Categories The relationships of the patterns concerned with designing Approval Processes as presented in this paper are shown in Figure3: This pattern collection is structured in five categories, which are presented in five dedicated sections later on: Manual Review Intensity, Involved Roles, Business Rule Usage, Execution Order, and Correction Strategy.These categories are further described in Table1.Patterns of the Manual Review Intensity category define how many Manual Approval Steps are included in the Approval Process: The 2-/4-/6-Eyes Principle and Dynamic Approvers pattern are located in this category.The number of Approvers are usually based on the risk of the Approval Object and regulatory requirements.If an Approval Process contains multiple Manual Approval Steps, the associated Approvers can be assigned by different strategies.Patterns describing different possibilities are contained in the Involved Roles category.Approvers can be More of the Same competencywise or have Different Competencies.Competencies in this context, for example, may involve skills and authority in an organization.Similarly, patterns contained in the Business Rule Usage category define whether there is an Automated Business Rule check and what purpose it has: Patterns in this category are Pre-Check Rule, Approval Steps Configuration Rule, and Fully Automated Approval Step.The category Execution Order contains two patterns concerned with the order of Approval Steps: either they are executed as a Sequential Approval or as a Parallel Approval.Finally, the Correction Strategy category contains three patterns for how to (not) support corrections in an Approval Process: A possible outcome is to Reject Ultimately.It may also be allowed that the Approval Requester may Correct and Restart Process or Correct and Repeat Step.
It is initiated by an Approval Requester and leads to the execution of Approval Steps.Approval Steps can be either Manual Approval Steps performed by an Approver or Automated Business Rules.
As part of Approval Process design it must be decided what to do, if an approval is denied.Consequently, patterns in the Correction category are concerned with how to react if there was a rejection in an Approval Step.
Possibility to Cure: This pattern does not allow the Approval Requester to make any corrections.The Approval Requester might choose to simply submit another approval if allowed and possible.Effort by Approval Requester: If Approval Requesters think the defect is curable they must initiate a new Approval Process, Possibility to Cure: This pattern allows the Approval Requester to easily correct findings.Effort by Approval Requester: Because the Approval Requester can correct findings without restarting, effort is reduced compared to the Reject Ultimately pattern.Effort in Approval Process: Effort is increased in the Approval Process because all already completed Approval Steps are repeated again.Review Consistency: Because all Approval Steps are repeated, consistency is kept.
organization must define what happens if one of the Approval Steps rejects an approval.If a curable defect is detected, the Approval Requester may correct it.Different options to correct or restart this defect influence how much effort is required by the Approval Requester.Effort in Approval Process: If a curable defect is detected, the point on where a correction re-triggers approval steps influences the effort required by the repeated Approval Steps.SolutionAllow the Approval Requester to correct the mistake and proceed the Approval Process by repeating the failing Approval Step.As shown in Figure17this pattern will allow the Approval Requester to make corrections to the Approval Request and repeat the failing Approval Step (in this case "Approval Step 2").Repeated executions of an Approval Step are slightly different from the first execution: Approvers already know the Approval Object to a certain extend and might only review the changes between the last and the newest version of an Approval Object.
Consequences Possibility to Cure: This pattern allows the Approval Requester to correct findings easily.Effort by Approval Requester: Because the Approval Requester can correct findings without restarting, effort is reduced compared to the Reject Ultimately pattern.Effort in Approval Process: Effort is increased in the Approval Process with the risk of "endless" correction loops which bind resources in the failing Approval Step.Review Consistency: Corrections may lead to findings that would have been found in previous Approval Steps and are missed with this strategy.