This documentation supports the 9.1 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

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
(Click the image to expand it.)



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
(Click the image to expand it.)



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.

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
(Click the image to expand it.)

Note

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 Get next approver manually.

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 Working with 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.

Was this page helpful? Yes No Submitting... Thank you

Comments