Setting Up and Working with Approvals

This chapter provides an overview of approvals and discusses how to:

• Navigate approvals components.

• Register approval transactions.

• Link workflow transactions.

• Configure approval transactions.

• Set up approval process definitions.

• Define dynamic approvals.

• Define notification templates for approvals.

• Define users for approvals.

• Set up the notification and escalation manager.

• Set up security for approvals.

• Administer approvals.

• Generate an approvals audit report.

• Work with self-service approval transactions.

Understanding Approvals

Many daily tasks are part of a larger process that involves several steps and people working together, such as the approval of a promotion. The term workflow refers to this process. To facilitate this type of multiuser process, PeopleSoft Enterprise provides approvals functionality, which enables you to automatically trigger workflow notifications to inform the next approver in the process of pending transactions.

Approvals Terminology

The following terms are important to the understanding of the approvals functionality and are used throughout the chapter:

Approval Workflow Engine

The Approval Workflow Engine (AWE) is the engine that provides the framework and capabilities for creating, running, and managing approval processes. The engine uses a series of database objects combined with application component configuration settings to determine how to process approvals using workflow.

Approval workflows are triggered when requesters submit a transaction, such as a promotion. The application hands the transaction over to the Approval Workflow Engine, which finds the appropriate approval process definition and launches the approval workflow. A set of approvers then carry out tasks related to the transaction.

The Approval Workflow Engine enables three levels of users to develop, configure, and use transaction approvals that meet their organizational requirements. For example, the process of submitting a promotion and getting it approved requires defining who will approve the promotion, 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, approval workflow provides an alternative workflow that is much easier to create, configure, and maintain. For example, all of the steps in approval workflow 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.

Approvals Business Process Flow

This diagram details the business process flow of implementing and using approvals functionality. It shows tasks that application developers, business analysts, and end users perform in conjunction with approval workflow.

Approval business process flow

Within the approvals business process flow:

• Application developers register information with the Approval Workflow Engine by using the Register Transactions page, where they register an application with the engine and describe its components, event handler, and records.

  As part of defining the registry, application developers create a record and table in which to store cross-reference information and set up notification templates for events. This definition determines the pending approval workflow process and tells an application which transaction is being approved or denied. Application developers also link the transaction component.

  Note.
  
  PeopleSoft Enterprise Human Resources delivers many transactions that are registered with the Approval Workflow Engine. Do not modify these transaction registry definitions because the system requires their setup to be as delivered. For a complete list of delivered transaction registry definitions, access the Register Transactions component by navigating to Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Register Transactions.

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

  The approval process definition includes setting up approval stages, paths, steps, recipients, and notifications for each approval process ID. Analysts identify the approval transaction registry entry on which to base approval process definitions and then define the details of the process.

  Functional business analysts also define or review user list definitions, email template definitions, and transaction configuration settings.

  After completing the setup, functional business analysts are responsible for maintaining and troubleshooting approval process transactions.

• Requesters submit a transaction for approval.

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

• 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.

• Approvers take actions on transactions.

  They can approve or deny requests, monitor transaction statuses, and audit approvals. When an error or violation of criteria or rules occurs during the approval process, the system notifies the approvals administrator, who interacts to resolve the issue.

• Reviewers view the transaction.

Approvals Design

After an approval process is defined, validated, and made active, the system can process a transaction for approval. Each PeopleSoft application typically has a top-level database record that distinguishes one transaction from the next. For example, the top-level record for eProfile Manager Desktop application's promotion transactions is HR_PROMOTE_DAT. These top-level records are called header records. When a transaction is submitted for approval, the Approval Workflow Engine 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.

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 definition 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. The workflow engine 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 participants 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, SQL objects, or by using custom application classes. Once the required number of approvers have approved a step, the approval workflow advances to the next step. If the Approval Workflow Engine 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:

The approval process

The above diagram is an example of request to transfer an employee from one department to another, illustrating the flow of the request through the various stages, paths, and steps of an approval process definition.

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. Then, these transactions can have children records (line-level records) of this header record. Note that line-level records do not exist for all transactions. PeopleSoft Enterprise Human Resources does not deliver any transactions with line-level processing because the transactions require no line-level records.

The approval process uses an application’s header keys to correlate approval processes and application transactions. For example, when you open an application transaction, the Approval Workflow Engine 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.

When you need to track an approval status at a lower level within a transaction, an analyst can configure the approval process so that different line-items in the same request follow different routes. In such cases, the Approval Workflow Engine splits the workflow into constituent line items, and enables analysts to configure the approval process so that different line items in the same request follow different routes. These lines of the workflow are still part of the same request, however, and should be tracked as such.

You can deny some lines of a transaction and approve others, making line-level approvals independent for each line. For example, a transaction can contain multiple lines, and you might want to use special approvers for certain items. You can add specialized approvers to approve transactions that are in their area of expertise.

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

Additional Approvals 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

During the approval process, approvers can add other approvers or reviewers to the current or a later stage of the approval process.

For example, if a manager wants approval from the requester's previous manager, she can add the manager as an approver. 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 approval process definition used for other requests.

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. Reviewers do not have authority to take action on a request.

Self-Approval

In some instances, 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 type of transaction that is eligible for self-approval, such as a promotion or pay rate change request.

Route to Requester

Route to requester is a feature that informs the system that an approval should be sent to a requester under certain circumstances.

For example, if a vice president submits a promotion request on behalf of a direct report at the supervisor level, the system will send a notification to the supervisor for whom the request was made. The supervisor remains part of the approval process.

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 submits a job requisition for her department, 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 workflow routing.

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. First, the system determines whether the transaction has been delegated. If then system does not encounter delegation, then the system determines whether alternate users are defined in the User Profile. Navigate to PeopleTools, Security, User Profiles, User Profile.

Push Back

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.

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 Administer Approvals component 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.

Sources of Information

The Approval Workflow Engine is a common component that is shared across multiple PeopleSoft Enterprise applications both within HRMS and other product families. For the HRMS product family, you'll find documentation pertaining to the Approval Workflow Engine in various locations:

• This present chapter describes the common Approval Workflow Engine functionality that applies to all product families as well as the setup steps and details that are specific to the HRMS product family.

• The Enterprise HCM 9.0 Approval Workflow Engine red paper, which is posted on the PeopleSoft Customer Connection website, is a step-by-step guideline for application developers on how to integrate applications with the Approval Workflow Engine. The red paper describes all object construction steps in detail and provides additional information on the setup within the application pages.

• Application-specific HRMS PeopleBooks (such as the PeopleSoft Enterprise Absence Management 9.0 PeopleBook) expand on all of the above texts by providing approval workflow details that relate to delivered business processes.

Before implementing, you should read all relevant sources of information to gain a complete understanding of how the pieces fit together.

Implemention of HRMS Transactions for Approval Workflow

PeopleSoft delivers many approval transactions that are already configured to work with the Approval Workflow Engine. For delivered transactions, you should review the delivered transaction data within the application pages to ensure that the data fits your business processes.

To review delivered HRMS transactions for use with the Approval Workflow Engine:

1. Register the approval transaction in the Approval Workflow Engine through the Register Transactions page.

   See Registering Approval Transactions.

2. Link Human Resources self-service transactions to the Approval Workflow Engine through the Workflow Transactions page.

   See Linking Workflow Transactions.

3. Set up the configuration options for the approval transaction on the Configure Transactions page.

   See Configuring Approval Transactions.

4. Set up the approval process definition through the Setup Process Definitions component.

   See Setting Up Approval Process Definitions.

   To set up the approval process definition:

   1. Define the stages, paths, and steps of the approval process definitions on the Setup Process Definitions page.

   2. Define criteria for workflow approval processes at the definition, path, and step level on the Criteria Definition page, which is accessed through links on the Setup Process Definitions page.

   3. Set up path details for workflow approval processes on the Approval Path Definition page.

   4. Define step details for approval workflow processes on the Approval Step Definition page.

   5. Define dynamic approvals through various components.

      See Defining Dynamic Approvals.

5. Create email templates for the approval transaction on the Generic Template Definition page.

   See Defining Notification Templates for Approvals.

6. Maintain user list definitions for the approval transaction on the User List Definition page.

   See Defining Users for Approvals.

7. Set up the Notification and Escalation Manager.

   See Setting Up the Notification and Escalation Manager.

8. Set up the appropriate permission lists, roles, and web libraries through PeopleTools security components.

   See Setting Up Security for Approvals.

If you need to implement other transactions for use with the Approval Workflow Engine besides the delivered transactions, you must complete additional implementation steps. These steps include those involving object construction within PeopleTools Application Designer and those involving setup within application pages. For technical details on how to implement additional approval transactions, see the Enterprise HCM 9.0 Approval Workflow Engine red paper, which is posted to the PeopleSoft Customer Connection website.

See PeopleSoft Customer Connection, Enterprise HCM 9.0 Approval Workflow Engine

Navigating Approvals Components

PeopleSoft Enterprise HRMS provides custom navigation pages that contain groupings of folders that support a specific business process, task, or user role.

Note. In addition to the PeopleSoft Enterprise HRMS custom navigation pages, PeopleSoft provides menu navigation and standard navigation pages.

This section discusses how to use the custom navigation pages to navigate in the components for approvals functionality.

See Also

Enterprise PeopleTools PeopleBook: Using PeopleSoft Applications

Pages Used to Navigate Approvals Components

This table lists the custom navigation pages that is used to navigate in the setup and administrative components for approvals functionality:

Registering Approval Transactions

This section provides an overview on the approval transaction registry, lists prerequisites, and discusses how to register approval transactions.

Understanding the Approval Transaction Registry

The approval transaction registry is the interface that developers use to register a PeopleSoft Enterprise application's transaction with the Approval Workflow Engine. Using the Register Transactions page, developers define how the system interacts with portions of the application that have been defined for approvals. Transactions that require approvals are candidates for being linked to the Approval Workflow Engine. Developers can use the Register Transactions page to link the components, event handler, records, and classes that they created through PeopleTools Application Designer for an application transaction (such as a job offer or employee absence request) into the approval process. The transaction definition itself is the metadata which describes the transaction make up to the Approval Workflow Engine. In some cases, you might add a transaction or make changes to a transaction. Application developers can register the main records and components that make up the transaction, then functional business analysts can select the approval transaction on which to base the approval process definition.

Delivered Approval Transaction Process IDs

PeopleSoft Enterprise HRMS delivers several approval transaction process identifiers that are common across applications for use with the Approval Workflow Engine. The system uses these process IDs specifically for registering delegation-related transactions with the Approval Workflow Engine so that the approval framework, which handles the requests, can communicate back and forth with the delegations framework.

When registering approval transactions with the Approval Workflow Engine on the Register Transactions page, you must specify a header record for the approval transaction. As part of their definition, each of these delegation-related Process IDs include the HCDL_DELEGATION header record and select fields. When you are configuring these Process IDs in the Configure Transactions component, you can use this header record and any of the listed fields to define additional criteria for the processing of the approval transaction. You define this additional criteria on the Criteria Definition page, which is accessible through the Configure Transactions component. Fields not listed on the Register Transactions component are not available for the criteria definition.

This table lists the approval transaction process IDs that PeopleSoft Enterprise HRMS applications deliver:

Note. Refer to the corresponding documentation in your application-specific PeopleBooks for information about delivered approval transaction process IDs that are specific to an application.

Note. Any PeopleSoft delivered approvals will already have the Approval Transaction Registry populated. No additional configuration is typically needed.

Prerequisites

Before registering approval transactions, you must create all of the required objects in PeopleTools Application Designer.

To complete the prerequisites for defining the approval transaction registry:

• Create a Transaction Handler Application class that extends an approved event handler class delivered by approval workflow.

• Create notification templates for the events, which include approval and denial for header and line levels.

• Create transaction data sources, as needed.

• Create views on transaction tables that will serve as criteria sources.

• Create a view to serve as a source for ad hoc users.

• Create a view to serve as a source for approver contact information.

See Also

Implemention of HRMS Transactions for Approval Workflow

Page Used to Register Approval Transactions

See Also

Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

Registering Approval Transactions

Access the Register Transactions page.

Process ID	Enter a name the system uses to track this approval process for a transaction. You can also enter a description for the approval process.
Object Owner ID	Select the PeopleSoft application to which this object belongs.
Cross Reference Table	Select the table used to manages application specific transaction records and associate them with the approval process run time instances. Each time a request launches an approval process, the system tracks the process by the header and line-level records of the application. To relate the approval process instance to the transaction instance, the cross-reference table holds the correspondence. For a given application transaction record, this cross-reference information helps you determine the pending approval process and to define to the application which transaction is being approved or denied. Application developers must create a record containing the applications keys, and include an Approval Workflow Engine-supplied subrecord. Developers must also build the underlying table.

Notification Options

Identify whether you will be using email or worklist notification, or both.

Default Approval Component

Identifies the default component that users should go to when selecting a worklist entry.

Approval Event Handler Class

Use this section to define the application class used to monitor events for this transaction. Each time an event occurs, the Approval Workflow Engine notifies the application. For applications to receive the notifications, application developers must extend the event handler class, ApprovalEventHandler.

When a transaction results in an action from the Approval Workflow Engine, the event handler class you specify determines how to proceed with the transaction.

The event handler base class defines the handler methods that you can override by extending classes. The extending class must have a no-argument constructor, since the system instantiates the class with no arguments.

This table explains the various event handler methods for which the system passes arguments to provide the specific context for each event, and gives examples of how an application, in this case PeopleSoft Enterprise HRMS, may act:

See PeopleSoft Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

Approval Status Monitor

Use this section to control how the system processes ad hoc approvers. Any approver can add or remove ad hoc approvers and reviewers.

Transaction Approval Levels

Use this section to define if the transaction is to be approved at the header or line level and what level the application supports.

Level Record Key Field Label IDs

Use this section to define the fields that are used for the transaction. All key Field Names appear for each Record (Table) Name that is listed. You can define criteria against only the fields that are defined here.

Linking Workflow Transactions

This section discusses how to link workflow transactions.

Page Used to Link Workflow Transactions

Linking Workflow Transactions

Access the Workflow Transactions page.

The Workflow Transactions grid and the Approval Workflow Engine (AWE) and Delegation Transactions grid are mutually exclusive. You cannot register the same transaction in both grids. If attempted, the system displays an error, and you must delete one of your entries before saving the page.

Workflow Transactions

Use the Workflow Transactions grid to register self-service transactions that use existing workflow configuration from a previous release. For example, if the self-service transaction is currently configured to update core records upon final approval via a component interface, you can list the transaction the Workflow Transactions grid so that you can still leverage these configuration values.

Approval Workflow Engine (AWE) and Delegation Transactions

Use the Approval Workflow Engine (AWE) and Delegation Transactions grid to register self-service transactions that use the Approval Workflow Engine framework and Delegation framework. The data that you enter into this grid links the transaction name and accompanying tables for HRMS self-service transactions to the approval process IDs that you create for these transactions on the Register Transactions page as part of the Approval Workflow Engine setup.

Note. You can only list a particular transaction once. You cannot assign the same Approval Workflow Engine transaction to multiple HR_TRANSACTIONS because this violates Delegation processing requirements.

Transaction Name	Enter the name of the self-service transaction in either one grid or the other, not both.
Category	Assign the self-service transaction to a category. Generally, all self-service transactions are assigned to the HR_TRANSACTIONS category. You can set up categories in the Workflow Transaction Categories page.
Description	Enter a description of the self-service transaction.
Approval Process ID	When implementing the Approval Workflow Engine framework, you define a unique transaction registry ID, called a process ID, for each of your HRMS self-service transactions on the Register Transactions page. Select the approval process ID that you have defined for this self-service transaction. By creating this link between the self-service transactions and the Approval Workflow Engine, the self-service transactions can dynamically retrieve this approval process ID by transaction name and thus invoke the Approval Workflow Engine framework. The Approval Workflow Engine framework requires this parameter during processing.
Delegation Initiation	Select to enable delegation of transaction initiation for the corresponding self-service transaction that uses the Approval Workflow Engine framework. The transaction then becomes available for configuration as an initiate-type delegation transaction. Configure delegation transactions on the Configure Delegation Transaction page.
Delegate Approvals	Select to enable delegation of transaction approval for the corresponding self-service transaction. The transaction then becomes available for configuration as an approval-type delegation transaction. This functionality is available only for transactions that you register with the Approval Workflow Engine framework in the lower grid. If you select both the Delegation Initiation and the Delegate Approvals check boxes, you can configure the transaction for delegation of initiations and approvals. Configure delegation transactions on the Configure Delegation Transaction page.

See Also

Setting Up and Working with Delegation

Configuring Approval Transactions

This section discusses how to configure approval transactions.

Understanding Approval Transaction Configuration

Use the Configure Transactions component to select and define elements that determine what triggers a notification, who receives the notification, and the content of the notification. Notifications are mapped to work with the approval transaction registry and include menus and components and SQL definitions. The events for which the system sends notifications include:

• Launch of the approval process on a transaction.

• Queue of approval step to an approver.

• Queue of a review step to a reviewer.

• Denial of a line or header.

• Approval of a line or header.

• Completion of the approval process.

Recipients of notifications include requesters, approvers, and reviewers, who can receive their notifications through either Worklist entries or email notification. When using email notifications, you must create email templates.

Page Used to Configure Approval Transactions

See Also

Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

Configuring Approval Transactions

Access the Configure Transactions page.

Ad Hoc Approver Options

Notification Options

This section appears only if you select the Use Email Approvals check box on the Register Transactions page for the given process ID.

User Utilities

User Utilities are the mechanism that the user changes to modify the behavior of delegation and reassignment.

For HRMS transactions, the workflow engine requires that you enter specific values in the User Utilities section to enable it to interact with the Approval Workflow Engine framework and Delegations framework. In the User Utilities Package field, you must select the value HCSC_USER_UTILITIES. In the User Utilities Path field, you must select the value UserUtilities. PeopleSoft Enterprise HRMS delivers these values.

Note. The user utilities class checks users against delegation to determine if the users have delegated their authority. If not, then the user utilities class determines whether the users have an alternate user in their user profiles.

Events

Use the Events section to define event parameters to trigger workflow notification. This section defines the information to build the default URL to include in notification for each of the participants that you specify in the Notifications section.

Notifications

Use the Notifications section to define who to notify and how to notify them in addition to the defaults determined in the Events section of this page.

These options enable you to notify participants who have not responded to a particular transaction or request. You can set the set the number of hours and maximum number of times to notify each participant by event. For example, you can have the Approval Workflow Engine notify the requester every two hours on final approval, not to exceed five notifications. The Approval Workflow Engine triggers the notification only if the participant has not acted on the transaction or request.

See Also

Defining Notification Templates for Approvals

Setting Up Approval Process Definitions

This section discusses how to:

• Set up approval process definitions.

• Define criteria for approval processes.

• Define paths for approval processes.

• Define steps for approval processes.

• Review an example HRMS approval process definition.

Pages Used to Set Up Approval Process Definitions

Setting Up Approval Process Definitions

To set up approval processes, use the Approval Process component.

Access the Setup Process Definitions page.

Business analysts use this page to define an approval process definition. The process is made up of stages and their paths and steps. The approval steps that you place on the approval path represent the approval levels that are required for a transaction.

You can develop approval processes that:

• Meet organizational or tiered approval limits.

• Use alternate hierarchies, such as supervisor approval and department approval.

• Use multiple parallel tracks, such as division and HR approvals at once.

• Use staged tracks, such as first receiving department approval and afterward receiving HR approval.

Typical approval processes might include:

• Employees or supervisors who can approve certain transactions.

• Two different approvers for each step, where both approvers at a step must approve the request for it to advance to the next step.

Stages

Paths

Steps

Defining Criteria for Approval Processes

Access the Criteria Definition page.

A criteria definition is a piece of arbitrary logic that, when evaluated, returns true or false. Criteria definitions program the Approval Workflow Engine, using transaction-specific information to change, for example, routing paths. To set the context for the criteria, the engine provides the transaction keys as bind values.

Use this page to define the different types of criteria you want to apply to an approval process at the approval process, stage, path, or step level. The level for which you are defining criteria on this page depends on the link that you click to access the page. You can create definitions consisting of a field with a logical operator and a value of definitions consisting of an application class that takes in transaction data to process the approval. Anytime the Approval Workflow Engine tries to launch an approval process, the engine first evaluates the criteria definition that is tied to the approval process definition. If the criteria definition returns false, the engine does not use the approval process definition. The engine then resolves the path and step criteria definitions in order.

Use this page also to define alert criteria. Alert criteria, although the same in principal as the other criteria types, is different in application. You can use alert criteria to decide when to display an alert. For example, you could decide to display a message to the approver on the Approve Transaction page if the transaction meets the specified criteria. To use this page to define alert criteria, click the Alert Criteria link on the Setup Process Definitions page. Alert criteria has two differences:

• The description field is the actual alert text that appears on the approval page.

• The criteria determines if an alert should appear on the approval page, as opposed to routing a line or header for approval.

User Entered Criteria

The system displays this section when you select the Criteria Type value of User Entered. Use this section to define additional criteria for the approval.

Field Criteria

The system displays this section when you select the Criteria Type value of User Entered. Use this section to select a record and field on which to control and filter ranges of data or types of data placed in the file you want to use in the approval process.

Monetary Criteria

The system displays this section when you select the Criteria Type value of User Entered. Use this section to establish approval criteria based on a value or amount. The system uses the values you define to determine the routing for approving the transaction. When the system evaluates the criteria for an approval process or a step or path within the process, it uses monetary values you define in this section.

The system uses values from fields in this section in conjunction with the Operator field to determine whether to run a step.

Application Class Criteria

The system displays this section when you select a Criteria Type value of Application Class. Use this section to assign application packages as criteria for the approval process definition. When you define a class, the system uses it along with other criteria you enter to process the approval.

Root Package ID	Select the primary application package. This selection is the parent class for other packages or for child application classes.
Application Class Path	Select a path that describes a specific class within the root package.

Defining Paths for Approval Processes

Access the Approval Path Definition page.

Use this page to set up additional parameters that determine how the system processes an approval path. Use the escalations feature to define time elements for when an approver takes too long to act on pending request.

Timeout Options

Defining Steps for Approval Processes

Access the Approval Step Definition page.

Use this page to set up additional parameters for the step definition.

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

See Also

Additional Approvals Features

Enterprise PeopleTools PeopleBook: PeopleSoft Workflow Technology, “User List Roles”

Reviewing an Example HRMS Approval Process Definition

This section provides an example of how set up an approval process definition for a transaction that is specific to PeopleSoft Enterprise HRMS.

In this example, let's suppose that our company wants to create an approval process definition to handle the approval of an employee's request for a day off. First you must define the stages, paths, and steps of your approval process.

Notice in the example that the approval process contains one stage, one path, and two steps. The stage in this example contains one approval path in the organization that requires two levels of supervisor approval before the employee is granted the day off. First, the employee's supervisor must grant approval, and then that supervisor's manager must approve the request.

You can define multiple stages, paths, and steps for an approval process definition. For example, perhaps you require administrator approval of the employee's day-off request. In this case, you would create an additional path within the existing stage that contains one step requiring administrator approval.

The Approval Workflow Engine processes multiple stages and steps sequentially. The engine cannot advance to the next step until you complete the preceding step in the given path. Likewise, the engine cannot advance to the next stage until you complete all paths within a given stage. For paths, however, you can define them as static (processed sequential) or dynamic (processed in parallel).

Now let's add logic that the Approval Workflow Engine evaluates at runtime for a Boolean result. You can define criteria at the definition, path, or step level. For this example, we want to add logic to the definition level that instructs the Approval Workflow Engine to stop processing if it encounters an absence request that is missing the employee ID value. To set up this criteria, click the Definition Criteria link at the top of the Approval Process Definition page.

Select the Criteria Type field value User Entered. This activates fields on the page that enable you to manually define your criteria. Also select the All Criteria Needed to Satisfy check box. The system selects this check box by default. Next use the Field Criteria group box to specify the necessary logic. In the Record field, select the header record for this transaction. You define header records for transactions on the Register Transactions page. In this instance, the process ID of the transaction is AbsenceManagement, which has a defined header record of GP_ABS_SS_DAT. Now choose between any of the fields that are defined within that header record for the process ID. In this example, EMPLID is selected. To complete the logic, select in the Criteria Operator field, the Is Not Blank value. Click Apply and then OK.

The logic in this criteria definition states that when processing a request for time off, the Approval Workflow Engine uses this definition ID to process any transaction related to the AbsenceManagement approval process ID that contains employee ID as part of the transaction. If the transaction does not contain an employee ID value, the Approval Workflow Engine continues to search for another definition ID that matches the required criteria needed to process the transaction for the related approval process ID.

Next we want to require the Approval Workflow Engine to advance the approval to the next approver in the path if the current approver doesn't respond within three days. Click the Details link in the Paths group box to access the Approval Path Definition page.

You can use the Timeout Options group box to define what should happen to a particular transaction or request after a certain period of time. For instance, you can notify the participant, advance the approval, or reassign the approval after a certain number of hours or days have passed. You can have the request reassigned to a particular person in the database or to a predefined user list.

To meet the needs of this example, set the Escalate Option field to Advance Approval and the Days field to 3. Click OK.

Now that we have defined the approval process definition, let's look at a graphic representation. Click the Approval Process Viewer link at the top of the Approval Process Definition page.

The Approval Process Definition page enables you to view graphically your approval process definition and, if necessary, quickly modify the definition. Click the plus signs, minus signs, or correction buttons. For example, perhaps we have decided that it is best that there is a third approval step for an absence request. Click the plus sign after step 2.

The system returns you to the Approval Process Definition page and inserts a new row after step 2 for you to enter the new step. Click Save when you have completed your definition.

Defining Dynamic Approvals

This section provides overviews of dynamic paths and dynamic approval authorizations, and discusses how to define dynamic approvals.

Understanding Dynamic Paths

To use dynamic approvals, create one approval step that determines a list of approvers without setting up every step individually within the path.

Workflow processes are defined in stages, paths, and steps. The system looks at the stage to determine if the trigger for the workflow is recognized at the header or line level. Within each stage, there is a minimum requirement of one path. The path contains steps, which define the workflow triggers and the action to take if the criteria is met. Without dynamic paths, the approvals administrator creates a step for every possible approver. With dynamic workflow, the approvals administrator creates a single path where the system users a user list for the approval hierarchy.

Note. When self-approval is used and the requester is on the list of authorized approvers, that role is counted as one approval.

See Also

Defining User Lists

Understanding Dynamic Approval Authorizations

PeopleSoft applications use workflow to configure approval paths in two manners. The first configuration is to define every approval in step-by-step fashion. The second manner is to create dynamic approvals. Dynamic approvals enable you to create a single step that systematically identifies every potential approver, searches to find out if that approver has enough authority to complete the approval, and creates a visual path for users to view of all necessary approvers in the process. You can configure a dynamic path allowing supervisor roles to approve or deny a transaction, and stop the approval path when the system has determined that all criteria has been satisfied. The approvals administrator creates a user list that the system uses to select the appropriate supervisory approvers for a transaction and then checks for authorization. The dynamic path takes the prior approver into consideration.

Two keys to creating approval authorizations for dynamic paths are the system’s ability to:

• Check authorizations.

• Skip unauthorized users.

The system looks at the user list and the approval authorization to determine which users are required to complete the authorization. The system displays the non-required users as a skipped step instead of a pending step in the event that Skip Unauthorized is selected.

Pages Used to Define Dynamic Approvals

Defining Dynamic Approvals

To configure the dynamic approval authorization, the approvals administrator must:

1. Define user lists for dynamic authorizations through the User List Definition page.

   The Approval Workflow Engine delivers user lists that address the most common approval scenario of routing an approval to a supervisor. If the requester is an end user, his immediate supervisor cannot authorize more than 5,000.00 USD, and the job requisition is for 6,000.00 USD, then the requisition moves to the next level supervisor. The user ID for the direct supervisor is listed on the user profile.

   Note. To enable the Supervisor by User ID approval routing, you must have a supervisor assigned to your user ID for the job.

2. Create an approval authorization by authorizing roles and approvers for dynamic paths through the Approval Authorization page.

   The Approval Authorization page is available through PeopleTools but must be added to the portal navigation to render it available in the application. To add this page to portal navigation, navigate to PeopleTools, Portal, Structure and Content. On the displaying page, click Set Up HRMS, then Common Definitions, then Approvals, and then Authorization. Clear the Hide from navigation check box. Click Save. Then navigate to PeopleTools, Portal, Security Sync and run the portal security sync process so that the portal cache recognizes the changes.

   If you don’t specify a Definition ID, the authorization is generic. To create an approval authorization for specific definition IDs, you must add a line for each Definition ID.

   Note. If you activate self-approval on the Approval Authorization page, it replaces the self-approval on static path steps.

3. Define a dynamic approval path through the Approval Path Definition page.

   Note. When creating criteria within the path that will trigger the workflow engine to activate, be certain that you set up the final approver as Greater Than so that no gaps occur.

   To define a dynamic approval path:

   1. Select Dynamic for a dynamic approval path in the Step Source field.

   2. Select the Notify Admin on No Approvers check box to indicate that the approvals administrator is to be notified if the system does not find an approver for the path. This option is only available when the Step Source is Dynamic.

   3. Select the Skip Prior Steps for Requester check box to indicate that if one of the approvers in this path is also the requester, then the system is to skip all steps in the path prior to that approver's step.

   4. Select the Check Authorization check box to enable the approval authorization.

   5. Select the Skip Unauthorized Users check box to enable the approval process to skip users within the user list if the system determines that they can't satisfy all of the criteria for approval.

Example Dynamic Approvals

This diagram illustrates an example of a workflow routing setup for the standard method and a workflow routing that skips unauthorized users:

Example of skip approval scenario

In the example, the criteria for the workflow approval path is set up for Chris Baker to have approval authority for less than 1,000.00 USD monthly salary, Patrick Sanchez to have authority for less than 5,000.00 USD, VP to have approval for less than 25,000.00 USD, and CEO to have approval for a job requisition equal to or more than 25,000.00 USD.

Kelly Jones creates a requisition for 10,000.00 USD.

If the system is not set up to skip unauthorized users, the system displays Chris Baker, Patrick Sanchez, and the VP as pending steps in the approval path.

If the system is set up to skip unauthorized users, the system displays the approval path with the VP as the only listed approver, and will display Chris Baker and Patrick Sanchez as skipped.

See Also

Defining User Lists

Defining Notification Templates for Approvals

This section provides an overview of generic template definitions and discusses how to enter generic template definitions.

Understanding Generic Template Definitions

Anytime that the Approval Workflow Engine triggers an email notification, it constructs the email based on the notification rules that you have set on the Configure Transactions page. The engine bases the email on the template that you specify in the Template Name field in the Notifications group box on that page.

If you are using bind variables (%1, %2, %3 and so on) in your email notification template, you must also create an SQL object through PeopleTools Application Designer. The Approval Workflow Engine uses this SQL object to populate the bind variables that you define in your notification template. You assign an SQL object to an email notification through the SQL Object identifier fields on the Configure Transactions page.

The Approval Workflow Engine reserves the %1 bind variable as a placeholder for an auto-generated link within the email notification to an application component. If you do not want to display the auto-generated link in your email notification, exclude the %1 bind from the template variables that you list on the Generic Template Definition page.

The Enterprise HCM 9.0 Approval Workflow Engine red paper, which is posted in PeopleSoft Customer Connection, provides an example of an email template and how to define its associated SQL object.

See PeopleSoft Customer Connection,Enterprise HCM 9.0 Approval Workflow Engine

Delivered Notification Template for Approvals

Refer to the corresponding documentation in your application-specific PeopleBooks for information about delivered notification templates that are specific to an application.

See Also

Reviewing Delivered Notification Templates for Delegation

Page Used to Define Notification Templates for Approvals

Entering Generic Template Definitions

Access the Generic Template Definition page.

You use generic templates to establish common formats for ad hoc notifications.

For approvals, the first bind variable is used to store the URL that appears in the email.

See Also

Enterprise PeopleTools PeopleBook: Workflow Technology, “Using Notification Templates,” Defining Generic Templates

Defining Users for Approvals

This section discusses how to:

• Attach workflow roles to users.

• Define workflow for user profiles.

• Define user lists.

Pages Used to Define Users for Approvals

Attaching Workflow Roles to Users

Access the User Profiles - Roles page.

Use this page to attach workflow roles to users. A role is a class of users who perform the same type of work, such as clerks, buyers, or managers. A role describes how people fit into workflow.

Role user IDs determine how to route Worklist items to users and how to track the roles that users play in the workflow.

See Also

Enterprise PeopleTools PeopleBook: Security Administration, “Administering User Profiles”

Defining Workflow for User Profiles

Access the User Profiles - Workflow page.

Use this page to define alternate users who are part of the workflow process. You can define alternate users to handle approvals during the absence of the primary approver and supervisor.

Note. Refer to the Setting Up and Working With Delegation chapter if you are using the Delegation functionality and want to use the Alternate User ID.

Defining User Lists

Access the User List Definition page.

A user list is a collection of users (PeopleSoft Operator IDs) expressed as the result of an SQL statement, PeopleSoft role, or PeopleSoft Application Class. User lists are used to represent the business process of your approval hierarchy on a transaction-by-transaction basis. PeopleSoft delivers pre-defined user lists. If none of the delivered user lists apply to your organization’s hierarchy, then you can define your own using the Maintain User List component.

When you select a user list source type, you must also select a corresponding value. You can only select one user list source for a user list. The SQL Definition, Query, and Application Class user list sources are dynamic, and can use input values to help identify users.

Delivered User Lists for HRMS

PeopleSoft Enterprise HRMS delivers the following common user lists for use with the Approval Workflow Engine:

Note. Refer to the corresponding documentation in your application-specific PeopleBooks for information about delivered user lists that are specific to an application.

Multiple Jobs and User Lists

PeopleSoft Enterprise HRMS delivers a series of user lists, or approval hierarchies, based on application class that is designed specifically for receiving and passing employee job information. These user lists correspond to the roles within an organization and enable you to select which job the Approval Workflow Engine uses to route approvals for employees with multiple jobs.

If an employee with multiple jobs encounters a job-related transaction during self-service approvals processing, the system prompts the employee to select the job for which she or he wants to process the transaction. For multiple job capability, the delivered user lists use an Application Class as the source for the user list, with the value of the Root Package ID field set to HCSC_USERLIST_UTILS and one of the following delivered Application Class Path values:

The delivered user lists correspond with different access types that PeopleSoft Enterprise Human Resources delivers with direct reports functionality. The system uses each of these delivered user lists in correspondence with how you define your direct report structure (by supervisor, by department, and so on).

If you define a custom user list and want multiple job capability, then you must use these same application root package ID and application class path values. PeopleSoft Enterprise HRMS supports multiple job capability only in the predefined user lists that we deliver. Note that PeopleSoft Enterprise HRMS does not support multiple job capability for these custom user lists.

See Also

Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide

Setting Up the Notification and Escalation Manager

This section provides an overview of notification and escalation and discusses how to:

• Associate events to a server.

• Set up an escalation event.

• View event statuses.

• Set up a notification and escalation manager (NEM).

Understanding Notification and Escalation

NEM is a mechanism used to process notifications and escalations on a specified interval.

For example, escalations are used when an approver has not responded within a specified time period to a transaction that is pending approval. You can specify the time period (timeout) and you can specify alternate approvers to whom to notify and escalate the approval for further action. Timeout options are defined on the Approval Path Definition page.

Pages Used to Set Up the Notification and Escalation Manager

Associating Events to a Server

Access the Define Event Types page.

Setting Up an Escalation Event

Access the Define Events page.

Viewing Event Statuses

Access the Event Status page.

Log Delete Options

Notification Manager

Setting Up a NEM

Access the Schedule JobSet Definitions page.

Setting Up Security for Approvals

After you define all necessary objects in PeopleTools Application Designer and complete the required setup in the application components, you must ensure the proper setup of the applicable permissions lists, roles, and web libraries.

This table describes the delivered permission lists for the approval framework:

PeopleSoft Enterprise HRMS delivers the AWE administrator role. This role already has the HCCPSCAW1010 permission list assigned to it. However, this role is not attached to any users as delivered. If you do not have an application-specific administrator role, then you can use this role by attaching it to any application-specific administrator users that you have. If you do have an application-specific administrator roles within your organization, then PeopleSoft recommends that you simply attach the HCCPSCAW1010 permission list to that role.

To enable users to view additional information about AWE participants through the approvals status monitor, you must assign users the correct permissions. Because of the manner in which the system displays the approvals status monitor, you must also grant access to the WEBLIB_PTAF web library for the appropriate product permission lists. Also, for users to be able to use the EMC functionality that is part of the Approval Workflow Engine, you must grant permission lists full access to the WEBLIB_PTAFEMC web library. PeopleSoft Enterprise HRMS delivers these two web libraries as part of the delivered Approval Workflow Engine permission lists.

To grant permission lists access to web libraries:

1. Navigate to PeopleTools, Security, Permissions and Roles. Permission Lists.

2. Select the permission list for which you want to grant access to web libraries.

3. On the Web Libraries page, insert a new row for the web libraries WEBLIB_PTAF and WEBLIB_PTAFEMC.

4. For each web library, click the Edit link.

   The system displays the Web Library Permission page.

5. Click the Full Access button to grant access to all functions, or complete the Access Permissions field to grant access to specific iscript functions.

6. Click OK.

7. Save the permission list.

Note. The AWE framework assumes each person in the system has one valid operator ID. If you are using the approval process and allow your employees to have more than one operator ID, make sure they have the same roles and permission lists.

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Administering Approvals

This section provides overviews of approvals administration and discusses how to:

• Administering approvals.

• Administering approvals for a specific approval process.

Understanding Approvals Administration

The Administer Approvals component gives approvals administrators a view into all approvals to which they have access, as well as the ability to take necessary actions on pending approvals.

Actions available for the approvals administrator are:

Source End Actions

When a request is approved, the engine 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 Workflow Engine supports this trigger by providing a call-back mechanism for event notification. For example, when a promotion 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 transaction. 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 Workflow Engine notifies the application of significant approval-related events.

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

Approval Reassignment

You can reassign pending tasks to another approver, or an approvals administrator can reassign all tasks that belong to a specific approver to another approver. Use reassignment in the following situations:

• The approver chooses to redirect the task to another approver, thus delegating a specific task (step) to another approver.

• The approvals administrator decides to reassign all pending tasks within a step that belong to an approver to another approver.

  This reassignment usually occurs when an approver is unexpectedly absent and the approvals administrator reassigns all pending tasks to another.

When you redirect a workflow task to another approver, you can modify the approval process map.

Note. The Approval Workflow Engine is set up for administrative reassignment and escalations only.

Pages Used to Administer Approvals

Administering Approvals

Access the Monitor Approvals page for a view of the approval process.

Search Criteria

Mass Reassignment

Search Results

The system displays a unique section for each approval process that has approval transactions meeting your search criteria. Each section contains key fields that are unique to the specific approval process. You can filter your search results within a section by specifying key values and clicking the Filter button.

Administering Approvals for a Specific Approval Process

Access the Monitor Approvals page to take action on a specific approval process.

Approver	Select an approver. All approvers associated with pending steps within the approval process are listed.
Comment	Enter text to appear under the approval graphic in the Approval Comment History section.

Reassign Pending Tasks

Administrative Approve/Deny

Reassigning Tasks Assigned to You

To reassign your tasks to another approver, select a step assigned to you as an approver and request that the step be reassigned to an alternate. You must have an approvals administrator role to perform this task.

The Approval Workflow Engine reassigns that step to the newly appointed approver, and deletes the original approver’s worklist entry. The system creates a new worklist entry for the new approver, and notifies the new approver.

The Approval Workflow Engine adds a comment to the approval thread to log the reassignment.

Reassigning Tasks as an Administrator

To reassign a specific approver’s pending tasks to another approver:

1. Filter the display to present pending approval processes for the specific approver.

2. Indicate the steps to be reassigned and the users affected.

   The system submits a request to the Approval Workflow Engine to reassign all of the pending steps.

Once you have reassigned the pending tasks to a new approver, the approval path is updated and the approval transaction is routed to the new approver.

Note. You can create reassignments through the user profile. However, workflow reassignments through the user profile don't alter the actual approval process. Reassigning using the Monitor Approvals component performs the reassignment and creates the worklist for the new user.

The approvals administrator can also take action instead of reassigning.

Comments

Expand the Comments section or click the View/Hide Comments link to view the previous workflow streams. This section is available when the system has resubmitted the transaction due to a change in the transaction.

Generating a Approvals Audit Report

This section discusses how to generate an approvals audit report.

Understanding the Approvals Audit Report

The Approval Workflow Engine produces an audit trail for each approval transaction as the transaction passes through the approval process. This audit trail includes tracking the distinction between the actions of the original approver and his or her proxy. The Approvals Audit Report Application Engine process (HCSC_AWE_ADT) creates an audit report based on this audit trail and the run criteria that you enter on the Approvals Audit Report page.

The Approvals Audit Report (AWEAUDIT) report includes the following data regarding approval transaction requests as applicable:

• Transaction number, which the Approval Workflow Engine automatically assigns to each approval transaction request.

• Approval process ID, which is defined during setup of the approval process.

• Approval definition ID, which is defined during the setup of the approval process.

• Current approver's name, if the request is still pending.

• Current request status.

• Requestor's or originator's name.

• Proxy and Delegator's names, if applicable.

• Requestor's or originator's employee ID.

• Each approver's name.

• Transaction submit date.

• Transaction completion date.

Enter data into one or more of the fields to filter your report results. If you leave a field blank, the report process includes results for all possible values pertaining to that criterion. For example, if you specify the range of dates for which requests were submitted as January 1, 2006 to December 31, 2006, and a specific originating requester, then the system generates a report that includes all transactions requested by that person for 2006, regardless of approval process ID and approval definition ID.

You can view the report online in PDF format, print the report, save it, or rerun the report using different filtering criteria. You can also download the report to your local machine as a TXT, XLS, or CSV file. The top of the report displays the date and time stamp of when it was generated and a summary of the filter data selected. The report sorts the data by request submit date.

Page Used to Run the Approvals Audit Report

Generating an Approvals Audit Report

Access the Approvals Audit Report page.

Submitted After and Submitted Before	Enter a date range for which you want to include approval transaction requests in the audit report.
Approval Process ID	Select an approval processes ID to filter your report results to a specific type of appproval transaction.
Approval Definition ID	Select a specific approval process definition for which you want to filter your report results.
Requested By	Select a requester to filter your report results to approval transaction requests submitted by a specific person.
Transaction Status	Select a status to filter your report results to aproval transaction requests that currenty have the selected status.

Sample Approvals Audit Report

The following is a sample of the Approvals Audit Report:

Note. You can configure this report through the PeopleTools XML Publisher functionality.

Working with Self-Service Approval Transactions

This section discusses how to:

• Review approval transaction requests.

• Select a job for approval transaction requests.

Important! This section lists only the self-services pages for approval transactions that are common across multiple applications within the HRMS product line. For details about self-service pages that are specific to business processes within an application, refer to application-specific PeopleBooks.

Pages Used to Work with Self-Service Approval Transactions

See Also

Working with Self-Service Delegation

Reviewing Approval Transaction Requests

Access the Review Transactions page.

Users can view the status and details of approval transaction requests that are pending their approval, approved, denied, or terminated. The system displays the results in the grid. For each transaction in the grid, users can click the View Details link or the Approve/Deny link to access pages where they can review details of the transactions and take further action in the approval process.

Note. For archiving transactions that are stored in the Approval Workflow Engine, PeopleSoft recommends using the PeopleTools Archive manager component.

Selecting a Job for Approval Transaction Requests

Access the Select Job page.

If a user submits or approves a transaction and the user has multiple jobs, the user can select the job for which to submit or approve the transaction so that the system can route the request to the appropriate people.

Note. Refer to the Enterprise HCM 9.0 Approval Workflow Engine red paper for instructions on how to implement the Select Job page into your application.

See PeopleSoft Customer Connection, Enterprise HCM 9.0 Approval Workflow Engine