Understanding the Approval Framework

This chapter provides an overview of the Approval Framework feature and:

• The Approval Framework process flow.

• Header- and line-level approvals.

• Transaction approval flows.

• Approval features.

• Tasks in the Approval Framework.

Understanding the Approval Framework Feature

Many daily tasks are part of a larger process that involves several steps and people working together. The term workflow refers to this process, which could encompass, for example, the approval of a purchase requisition or a job change request form. To facilitate this type of multiuser process, the PeopleSoft product can automatically trigger workflow notifications to inform the next approver in the process of work awaiting them.

A specialized designer is available to address workflow approvals. This designer enables you to configure Approval Frameworks using existing components without writing code.

Three types of users come together to set up approvals. They include application developers, functional business analysts, and users, who include requesters, approvers, and reviewers. Approval Framework brings these roles together to define an approval process workflow.

Application developers set up Approval Framework using a transaction-definition component. Examples of a transaction might include a job change request or leave of absence request. Transactions are made up of an approval process, routing rules and steps, and a set of users who approve and review the transaction.

Using Approval Framework, you can:

• Approve or deny individual line items in a transaction.

• Approve and deny multiple transactions one at a time.

• Include multiple approvers for individual steps.

• Assign additional approvers and reviewers during the approval process.

• Escalate approvals.

• Approve, deny, or push back approvals.

• Reassign approval tasks to another approver.

• Use worklist and email notifications.

Understanding the Approval Framework Process Flow

Approval Frameworks are triggered when requesters originate a transaction, such as a purchase requisition or a job change request, and a set of approvers carry out tasks related to the transaction. The PeopleSoft Approval Framework process is a framework that enables three levels of users to develop, configure, and use transaction approvals that meet their organizational requirements. For example, the process of submitting a job change request and getting it approved requires defining who will approve the request, the order in which they will approve it, and how it will be routed to approvers.

In contrast to the standard PeopleSoft workflow, which requires advanced technical skills in PeopleSoft PeopleTools to create and maintain, the Approval Framework provides an alternative workflow that is much easier to create and maintain. For example, all of the steps in Approval Framework are defined using PeopleSoft pages rather than underlying PeopleSoft PeopleCode, so functional users can design and maintain workflow using these online PeopleSoft pages instead of requiring technical developers to create workflow rules.

Many PeopleSoft products are delivered with integrated Approval Frameworks, consult your application documentation.

To implement the Approval Framework process, the framework for building and interpreting workflow approvals brings together these users:

• Application developers

  Application developers adapt applications for approval with minimal coding, using a defined setup process. Making this possible is the Approval Framework, which provides a common implementation that other applications can use. Application developers integrate their applications with the Approval Framework using the Register Transactions page, where they register an application and describe its components, event handler, and records. The register stores the approval process IDs that developers create for applications.

  Note. The PeopleSoft product delivers the transaction registry for delivered Approval Framework processes.

  After an end user creates an application transaction and submits it for approval, the application hands the transaction over to the Approval Framework, which finds the appropriate approval process definition and launches the Approval Framework.

• Functional business analysts

  Functional business analysts design Approval Framework for use with an application. This includes setting up stages, paths, steps, recipients, and notifications for each approval process ID. Analysts identify the application-supplied transaction definition on which to base approval process definitions. They use the Approval Process Definition page to define processes for approving transactions. These processes can be used repeatedly to guide transactions through their approval process.

  Many businesses need different approval routings for different types of transactions. To support such variations, you can configure multiple approval process definitions for each transaction within an application. In addition to process IDs, approval process definitions are effective-dated.

• End users

  End users create transactions and then use an approval process with approvers and reviewers within an approval flow. Using this process, the different end users can approve or deny requests, monitor transaction statuses, and audit approvals.

Understanding Transaction Approval Flows

After an approval process is defined, validated, and made active, the system can submit a transaction for approval. Each PeopleSoft application typically has a top-level database record that distinguishes one transaction from the next. These top-level records are called header records. When a transaction is submitted for approval, the Approval Framework combines the approval process definition with the header record instance and line records, if line level approval is configured, to create a unique approval process instance. This approval process instance is routed from approver to approver, as configured in the approval process definition.

Approvals use two levels of processing: header and line. Business analysts set up the approval process definition that determines the flow of the approval at both levels. The approval process consists of:

• Stages

  A stage is one part of an approval process that can contain multiple parallel paths but must be at the same header or line record level. The system executes stages in sequence where one must complete before the next one begins. A stage can be at either a header level or at a line level. Stages at a line level make it possible for approvers to sign off separately on individual line items for a single transaction. Approval Framework sees each header and each line as individual pieces. A line is a child of the header. A header stage acts on the unique header while a line stage acts on each line. A stage consists of one or more paths.

• Paths

  A path contains a sequence of steps. Within a stage, paths execute in parallel. Path entry criteria determines whether or not a path executes for a given transaction or transaction line.

• Steps

  A step represents one or more approvers or reviewers. Steps within a path execute in sequence. Separate criteria for each step determines whether or not that step executes. Each step can also have a set of reviewers. Reviewers are notified about transactions that are pending approval by email, through the worklist, or both. However, the workflow proceeds without waiting for reviewers to act.

  The system notifies approvers by using email, worklist, or both, of pending approval steps, which can require one, all, or a fixed number of approvers. You can specify approvers by roles, queries, fixed lists, or by using custom application classes. Once the required number of approvers have approved a step, the Approval Framework advances to the next step. If the workflow has no further steps, it advances to the next stage.

Note. While the configuration may require multiple approvers to approve a step before it advances, any single approver can deny a step. The moment an approver denies a step, the transaction stops moving forward in the approval process. If the transaction is at a line level, other lines will continue to move forward. If the denial is at a header level, the approval process terminates, and the entire transaction is denied.

This diagram illustrates how the approval process uses stages, paths, and steps for routing approvals:

Example Approval Framework showing stages, paths and step

In this example there are 2 stages. In stage 1 there are 2 paths. Each step within the path is executed in sequence, when the required number of approvers have approved a step, it is advanced to the next step within the path. Paths are executed in parallel. When all paths within the stage are approved, the workflow advances to the first step in the next stage.

Understanding Header- and Line-Level Approvals

Many PeopleSoft transactions have a top-level record (known as a header) with keys that uniquely identify a single transaction in an application. In addition to the header record, a transaction may also contain a more detailed line level record (known as line-level).

The Approval Framework process uses an application’s header keys to correlate approval processes and application transactions. For example, when you open an application transaction, the Approval Framework enables you to submit the request for approval only if you haven’t already submitted it. This check is possible because the system correlates the application header keys with the approval process instance keys.

If a particular transaction supports line level processing, an analyst can configure the approval process so that different line-items in the same request follow different routes.

You can deny some lines of the request and approve others, making line-level approvals independent for each line. For example, a request can contain multiple lines, and you might want to use special approvers for certain lines based on their area of expertise.

Note. If a transaction has multiple line items, 1 of which is denied and the rest are approved, the overall transaction is approved.

An Approval Framework process might have mixed header and line-level approval routings. For example, department managers might exercise budgetary control over the request as a whole, while commodity approvers still examine only those line-items which fall within their expertise. Final approval requires both types of approvers to sign off on the request.

When a request is approved, the Approval Framework notifies the application, which then takes source end actions:

• End actions.

  An approval of one transaction often leads to the creation of another transaction, or triggers another business process. The Approval Framework supports this trigger by providing a call-back mechanism for event notification. For example, when a requisition is approved, it can be sourced—an action follows final approval, which is the end action.

• Line-level versus header-level end actions.

  Use line-level approvals to make it possible for an action to be taken on different line items upon their approval, without waiting for the approval of other line items in the requisition. You can source line items as soon as they are approved.

  This action is possible only if line-level approval routings are at the end of the process and require no further review. In this case, the application can act on the individual lines as they get approved. The Approval Framework notifies the application of significant approval-related events.

  Header actions allow the transaction lines to be grouped together and processed as one unit.

Understanding Criteria for Approval Framework Processes

Criteria is an entity that evaluates to true or false. It uses transaction-specific information to determine if a transaction requires approvals and follows the approval paths and steps that evaluate to true. To set the context for the criteria, the approval process definition provides the transaction keys as bind values.

Criteria is set up at three levels as shown in this table:

There are 3 different types of criteria you can apply to an approval process.

Understanding Approval Features

Using a combination of features, you can create rules for different types of approvals. This section discusses:

• Ad hoc path approval

• Ad hoc review

• Self-approval

• Route to requester

• Skip prior path

• Auto approval

• Alternate approvers

• Push back

• Approval comments

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 Registering Approval Transactions.

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.

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:

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 the requester is the only approver and neither route to requester or self-approval are selected, the system will produce an error and route the transaction to the administrator.

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

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

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. This approval does not pertain to any other line, but header approvals do imply line approval for this feature.

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.

Note. Alternate users are defined in the User Profile. Navigate to PeopleTools, Security, User Profiles, User Profile.

You can also use the FindAlternate method in the EOAW_CORE:Utils class to select alternate approver.

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.

Note. The push back feature ignores auto self-approval.

See Configure Monitor Approvals.

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.

Understanding Tasks in the Approval Framework

This section details the steps to implement and use Approval Framework. It describes tasks that application developers, business analysts, and end users perform in conjunction with Approval Framework.

To implement and use Approval Framework:

1. Application developers register information with the Approval Framework by using the Register Transactions page.

2. Functional business analysts define the approval process definition for an application transaction.

   Essentially, analysts determine the approval transaction registry entry on which the process definition is to be based and then define the details of the process. The approval process definition includes definitions of stages, paths, steps, and criteria.

3. Requesters submit a transaction for approval.

   This action launches the approval process. The Approval Framework reads the approval process definition and queues the transaction for approvers.

4. The system queues an approval task to an approver or reviewer using email notification, worklist entry, or both.

   The URL encoded in the worklist entry points to the corresponding approval component.

5. Approvers and reviewers take actions on transactions using the Approval Monitor. Reviewers may only add comments.

   When an error or violation of criteria or rules occurs during the approval process, the error is routed to the administrator for resolution, if there are no additional steps in the path.

   Note. The error conditions for static steps are no approvers or not enough approvers at a step.