Understanding Approval Features

Ad Hoc Path Approval

If Ad Hoc Approval Status Monitor is implemented for an approval transaction, then during the approval process, approvers can add other approvers or reviewers to the current or a later stage of the approval process. This action is called ad hoc approval, and it only applies to the approval instance in which the addition occurs and does not affect the underlying process definition used for other requests.

You can insert ad hoc approvers and reviewers in serial or parallel with existing approvers:

• For serial approvals, each approval in the process is sequential.

  Users can add approvers and reviewers only after the current pending step or later.

• For parallel approvals, the sequence does not matter.

  Users can insert an ad hoc step in an ad hoc path in any currently pending or subsequent stage.

You can add ad hoc approvers once the transaction is submitted. The Approval Framework launches the previewed approval process instance if requested by the application developer's code.

If you have an ad hoc approver user list defined in the transaction registry, only the users within that list can be added as an ad hoc approver or reviewer.

See Register Transactions Page.

Ad Hoc Review

Ad hoc reviewers are users that an approver or requester would like to review a transaction. Ad hoc reviewers are notified and provided with a link in a worklist entry or email to the transaction, if the process is so configured. Ad hoc reviewers do not approve or deny transactions, they can add comments. However, the comments should not contain the % symbol as this is not recognized as a valid character and the application will remove this from the comments.

Self-Approval

A requester can also be an approver. If requesters approve their own transactions, it's called self-approval. A check box setting enables self-approval. If enabled, the requester’s approval is assumed, and the process continues. However, you can establish criteria that helps control the requester's approval authority. For example, you can place a limit on the dollar amount for the requester so that if the transaction is over that amount, the requester is not used as an approver.

If self-approval is not enabled, then the requester must manually approve the transaction.

If self-approval is enabled, then the self-approval criteria must be specified. Then, if the requester appears as an approver, the criteria is evaluated. If the criteria are met, then the requester's approval is assumed and the minimum approvers for that step decrements by one.

When a requester is an approver, you can configure the path to skip the steps in that path prior to the requester's step.

Self-approval is configured at the step level.

Route to Requester

Route to requester is a feature that informs the system that an approval should be sent to a requester. In some cases the requester may already be listed in the approval path. The flow of this option is also dependant on the self-approval feature as displayed in this diagram:

Image: Route to requester and self-approval feature flow

Diagram illustrating the route to requester and self-approval feature flow.

• If route to requester is selected, the requester must always manually approve the transaction regardless of the self-approval setting.

  Note: Even if the self-approval criteria is met, the requester must manually approve the transaction.

• If neither route to requester nor self-approval are selected, and the requester is the only approver, the system tries to identify additional steps in the path and routes the transaction to the next step if available. If no additional steps are available, it generates an error and routes the transaction to the administrator.

• If neither route to requester nor self-approval are selected, and there are other approvers in the path, the requester approval is skipped.

• If route to requester is not selected and self-approval is selected, the self-approval criteria are checked. If the requester meets the approval criteria, the approval is assumed and auto-approved.

  If the requester does not meet the approval criteria, and other approvers are available, the requester approval is skipped. If self approval criteria are not met and there aren’t other approvers in the same step, the system routes the transaction to the next step in the process if applicable, or to the administrator if there are no more steps in the path.

Skip Prior Path

When skip prior to requester is enabled, the system begins the approval flow at whatever step in which the requester is an acknowledged approver.

For example, if a vice president orders supplies for herself, the system skips application approval steps leading up to the step for which the vice president is an acknowledged approver.

Auto Approval

When auto approval is enabled, the system remembers an approver's action for that process at the header- or line-level, and applies the same action automatically for any subsequent appearance in the Approval Framework routing.

For example, if the approver approves line one and the line appears again as a required approval for the specific approver, the approval is remembered for the line. In this example, the approval is given only to that specific line in the process. However, if an approval is made at the header level, approval is granted to all of its lines automatically.

As a hierarchical system, the Approval Framework supports auto approval in these situations:

• Header stage that is followed by another header stage.

• Header stage that is followed by a line stage.

• Header stage that is followed by a line stage, which is followed by another header stage.

• Line stage that is followed by another line stage.

Auto approval is not supported in processes where a line stage is followed by a header stage. The reason being that the approver of a line may only have approval privileges to some but not all lines within the same header and therefore should not be given the power to approve the header through the Auto Approval option.

Alternate Approvers

Alternate workflow approvers are users who are assigned to receive emails and worklist notifications for the primary approver when the primary approver is not available. When you identify an alternate approver, you enter a date range during which you want the alternate to fill in. The system determines if the alternate is in place for the date range.

Push Back

Push back is an optional feature that can be implemented in the Approval Monitor. If implemented, push back takes a currently pending step out of pending status and requeues the previous step to its approvers. The meaning of push back is that the approver is questioning the prior step’s approval and is requesting clarification. Push back is only possible within a path, therefore, the first step of a path cannot push back.

See Approval Monitor Configuration Page.

Approval Comments

Requesters can add comments to transactions, and approvers can associate their comments with the approval process rather than the request transaction directly. The Approval Framework Monitor provides a mechanism for associating comments with a particular approval process instance, which is tied to a particular application transaction. Approvers can view comments added by another approver, but they cannot change previous comments. Approvers should not use the % symbol while adding comments to transactions as this is not recognized as a valid character by the application and will be removed.