Approval processes

An approval process is the routing of an approval request through a defined series of steps until the process is done. The approval process requires signatures and is governed by  Approval Server rules and behavior. You can use Approval Server  to automate any business process, and you can customize the process to implement the operational guidelines of your organization. By using Approval Server , you can make sure that any process follows well-defined rules, that the right people are notified and the correct signatures are obtained, and that you can provide an audit trail of requests and the decisions made by approvers.

Difference between processes and rules

Understanding the difference between an approval process and the rules it uses is critical to implementing a business process with Approval Server .

• An approval process defines the routing of any item that requires signatures. An approval process can consist of many operations, transitions, and decision points, each contributing toward a defined destination. The approval process ensures that all the necessary steps take place to implement a business operation that requires signatures or approvals, such as approving new hires or signing purchase orders. In each case, the overall process is the same each time it is performed.
• Approval rules augment the standard behavior of the Approval Server , and govern how an approval request is handled at various stages of the approval process. You use rules to retrieve and save approval data and to make decisions during the process, such as who the next approver is, whether more signatures are needed, and whether the routing process is complete. For more information about approval rules, see Approval rules.

Approval process stages

The approval process ensures that all the necessary steps take place to complete any approval, while rules govern how the request is handled at various stages of the process. 

The following figure illustrates the five stages of any approval process. The Approval Server  checks for rules belonging to each stage during the approval process. Any given approval process does not require rules in all five stages, but most approval processes include rules in at least the approver response and Process Done stages. 

Depending on the process design and the rules used, the approval cycle can include several iterations of the next approver, approver response, and Completion Check stages. 

Approval process stages

An approval process starts when someone submits an approval request.

• Stage 1, Self Check—If the process includes either Auto Approval or Self Approval rules, the Approval Server  immediately applies them to determine whether the requester has sufficient authority to approve his or her own request. If so, the approval process is done and the approved request is returned to the requester.
• Stage 2, Next Approver (routing)—If no Auto Approval or Self Approval rules are included in the process, or if the Self Check stage determines that the request must be routed to an approver, the Next Approver stage begins. For most process types, the Approval Server  applies one or more next approver rules to start a cycle of identifying people who need to approve the request. (The exception to this is the Ad Hoc process type, as explained below.) The Next Approver stage is repeated until all approvers have received the request.
• Stage 3, Approver Response—In this stage of the process, approvers either approve or reject an approval request. This action completes the signature line for that approver. If an approver approves the request, the approval process continues. If an approver rejects the request, the approval process is usually done. (You can override this behavior with Signature Accumulator and Statistical Override rules).
  The Approver Response stage is repeated as necessary, and is closely integrated with the Completion Check stage.
• Stage 4, Completion Check—The Completion Check stage accepts the results of the Approver Response stage, and checks to see if the routing of a request is complete. Routing is complete if all required approvers have received the request, whether they have responded. If all required approvers have not received the request, the process returns to the Next Approver stage.
  The Completion Check stage is repeated as necessary until the Completion Check passes.
• Stage 5, Process Done—The approval process is done when the request is approved by all (or enough) required approvers, or when it is rejected. This stage is also done if an error state is recorded or if the request is cancelled. During this stage, the Approval Server  determines whether the approval was successful, and takes appropriate action, such as delivering a notification of the completed request to the requester.

The difference between "complete" and "done" is important. When a request is complete, it has been routed to all approvers. Even when routing is complete, all required approvers have not necessarily responded. The request is done when all required approvers have approved or rejected the request.

Approval process types

The Approval Server  provides process types that you can choose from when designing an approval process. The following process types differ in how the approval server identifies the next approver:

For an example of each process type, examine the sample applications installed with Approval Server . For information about how to create, modify, and delete processes, see Defining an approval process. For information about rules and how they are used with each process type, see Approval rules. For information about creating rules, see Defining approval rules.

Parent-Child process

The Parent-Child process type uses the relationships between requesters and approvers, and between approvers and other approvers, in conjunction with a Get Next Approver rule, to determine the routing of an approval request. You define these relationships in a signature authority form. 

The Management Cost Authorization process in the Lunch Scheduler sample application is an example of a Parent-Child rule. It uses the Manager Login Name field on the AP-Sample:Signature Authority form to define the "parent" login name of each sample user. 

In a process where each approver has a defined relationship to the next approver, such as employee to manager and manager to director, the most appropriate process type is usually Parent-Child. In this type of process, the approval request is routed up an approval hierarchy from the "child" (requester or previous approver with lower authority) to the "parent" (approver with higher authority). A manager-employee relationship is often the hierarchy represented with a Parent-Child approval process. 

The following figure illustrates an example Parent-Child process, in which an engineering change must be approved by a hierarchy of approvers. 

Parent-Child hierarchy 

In a Parent-Child process, the Approval Server  automatically routes the request to the next approver according to the defined relationship. Persons represented by "X" in the diagram do not receive the approval request because they do not have parent relationships with the requester or any approvers. 

A rejection from any approver rejects the request for everyone in the hierarchy. This is also true if the process uses two or more separate approval hierarchies. Process administrators can configure notifications to inform all approvers when any other approver has rejected a request.

The following considerations apply to a Parent-Child process:

• A Parent-Child process requires a Get Next Approver rule that defines how to find the next approver. This rule must include the name of the field containing the identity of the parent and must return the Approver List, which is a string of individuals or roles. See Defining Get Next Approver rules.
• When an approver marks an approval request as approved, the approval server automatically checks for the parent of that approver and, if one is found, routes the request to that person.
• When it generates the first Approver List for a Parent-Child process, the approval server assumes that the "previous" approver is the originator of the approval request (the requester). This means that the parent of the requester becomes the first approver.

Level process

The Level process type uses a hierarchical set of organizational levels, in conjunction with a Get Next Approver rule, to determine the routing of an approval request. The process administrator defines the organizational levels and their members in a signature authority form. 

The Major Account Level Approval process in the Lunch Scheduler sample application is an example of a Level process. It uses the Account Approval Level field of the AP-Sample:Signature Authority form to define organizational levels and the sample users who belong to them. 

If anyone in a certain organizational position, such as a job level, can approve a request, the Level process type is often the best fit. In a Level process, the Approval Server  delivers the request to all approvers in the next level. When the defined number of approvers in any level have approved the request, the approval server routes the request to the next level. 

The following figure illustrates a request for a soft drink machine to be placed in a company courtyard. The request must be approved by the refreshment, landscape, and maintenance committees. The Level process defines the order in which the committees see the request. 

Level process with three levels
 

In a Level process, a request must be approved by at least one approver in each level before it passes to the next level. The approvers for a given level can consist of individuals or roles. A Level process does not dictate the number of approvers on each level. You can set up routing to the next level to require signatures from any number of individuals in each level. For information about configuring roles, see Defining roles for an approval process. 

A Level process uses a level value to indicate the position of individuals or roles. The Approval Server  uses the value in the level field to determine an approval sequence, starting with level 0. The highest level is 1000. The Approval Server  skips over unused levels.

The following considerations apply to a Level process:

• A Level process requires a Get Next Approver rule that defines how to find the next approver. This rule must identify the name of the field containing the level identifier, and must return two values: a level indicator, and a string of individuals or roles. See Defining Get Next Approver rules.
• The process rules must be configured to determine whether a request should be routed to more than one person in each level.

Ad Hoc process

In an Ad Hoc process, no Get Next Approver rule is used, and the process administrator does not define approver or organizational relationships. Instead, the requester and the approvers designate the next approver or a set of approvers while working with the request. The requester enters at least one approver when creating the request. Approvers can add additional approvers when they respond to the request. 

The Issue Approval process in the Get Agreement sample application is an example of an Ad Hoc process. 

Routing two requests in the same Ad Hoc process

An Ad Hoc process is not the same as an ad hoc override. Ad hoc overrides allow specific approvers to alter a predetermined routing. An Ad Hoc process includes no predetermined routing. See Next Approver stage rules.

When entering approvers, users must enter the exact  AR System login ID of the next approver. To prevent typographical errors and allow users to select from a list, the AR System administrator must construct field menus that contain the appropriate approvers for an Ad Hoc process. See Defining application menus.

Rule-Based process

The Parent-Child, Level, and Ad Hoc process types are partially preconfigured and, therefore, are relatively simple to implement. A Rule-Based process is similar to a Parent-Child process, except that a Rule-Based process relies on rules that you create to define the relationships between approvers. This option enables you to define a routing method that allows more complexity than predefined relationships. However, a Rule-Based process requires more thought and work to implement. 

The Special Overdue Approval process in the Lunch Scheduler sample application is an example of a Rule-Based process.