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.
Many daily tasks are part of a larger process that involves several steps and people working together, such as the approval of a promotion. To facilitate this type of multiuser process, PeopleSoft provides approvals functionality, which enables you to automatically trigger workflow notifications to inform the next approver in the process of pending transactions.
Many PeopleSoft applications are delivered with predefined approval processes. However, this chapter provides the PeopleSoft HCM product line specifics of the Approval Framework functionality. While this document lists the HCM navigation and additional topics specific to setting up HCM Approval Framework, more detailed overviews and field descriptions are documented in the companion documentation PeopleSoft PeopleBook: Approval Framework.
See Also
PeopleSoft 9.1 PeopleBook: Approval Framework
The following terms are important to the understanding of the approvals functionality and are used throughout the chapter:
A generic term referencing the business process of how a particular transaction is routed for approval within an organization. |
|
Engine that provides capabilities for the creation, execution, and management of approval processes. |
|
The definition of an approval process within the Approval Framework. The definition may contain stages, paths, steps, varying hierarchies, and criteria, among other configurable parameters. |
|
The ID associated with a particular approval process definition in the Approval Framework. Each transaction registered with the Approval Framework must have at least one process ID defined. |
|
A transaction that uses the Approval Framework for approval processing. For example, a promotion, transfer time off request, job requisition, and so on. |
|
A step has one or more approvers, whose actions are tracked. A step can be configured to require a set number of approvers to act, and has criteria which govern whether or not the step is to be active for the request under consideration. Steps are sequential. |
|
A path is a sequence of steps. For example, step two routes to its approvers only after step one is approved. A given approval could actually go through multiple approval paths based on some decisions. Paths can be mutually exclusive or parallel. They all converge at the final approval. |
|
A stage is a collection of approval paths. Approval stages come in a single sequence (stage 1, stage 2, and so on). An approval stage runs when it's immediately preceding stage finishes. When an approval stage runs, all the approval paths within it run simultaneously. The approval stage is considered complete when all approval paths within it have finished. |
|
The person who has been determined to have the authority to approve (deny, pushback, and so on) a request. |
|
The requester is the person for whom you want the Approval Framework to treat as the initiator of a request. In most cases the requester and originator are the same person. However, when using the Delegation feature the requester and originator of a request can vary. For example, if a manger delegates a transaction to a direct report and that direct report submits the transaction, the direct report is the originator and the manager is the requester. |
|
The person for whom a transaction is being processed. For example, Karen submits to her boss, Russell, a promotion request for one of her employees, Robbin. Karen is the requester (originator), Robbin is the subject, and Russell is the approver. |
|
The person who has management responsibilities for the requester or for an approver, as defined in your direct report settings during implementation. |
|
The system administrator who is responsible for configuring, managing, troubleshooting, and maintaining approvals. |
|
The Approval Framework engine is event driven. Events are typically actions that can be taken by a user in the system, actions such as submit, approve, deny, push back, and so on. |
|
Statuses typically represent the overall state a transaction is in, such as pending, on hold, approved, denied, terminated, and so on. |
|
Rules used to decide whether or not approval is required. Approval criteria fields and dimensions are data elements and attributes that are used to define the approval criteria. |
|
The organizational hierarchy that models the actual approvals required by a transaction type (for example, approval hierarchy by supervisor or department). |
|
Collection of users (PeopleSoft Operator IDs) expressed as the result of an SQL statement, PeopleSoft role, or PeopleSoft Application Class. |
|
A user can have another user in the system as his or her alternate approver for a specified period of time. This is set on the Workflow page of the User Profile component within PeopleTools security. |
|
Delegation is when a person authorizes another to serve as a his or her representative for a particular task of responsibility. With the Delegation feature, users can authorize other users to perform managerial tasks on their behalf by delegating authority to initiate or approve managerial transactions. |
The Approval Framework 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 Framework, 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 Framework 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.
See Also
Understanding the Approval Framework
Within the approvals business process flow:
Application developers register information with the Approval Framework 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 Human Resources delivers many transactions that are registered
with the Approval Framework. 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 Framework 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.
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
See Also
Understanding the Approval Framework Process Flow
Understanding Transaction Approval Flows
Understanding Header- and Line-Level Approvals
Understanding Approval Features
The Approval Framework is a common component that is shared across multiple PeopleSoft applications both within HCM and other product families. For the HCM product family, you'll find documentation pertaining to the Approval Framework in various locations:
This present chapter lists the Approval Framework functionality that applies to the setup steps, navigation paths, and details that are specific to the HCM product family.
Application-specific HCM PeopleBooks (such as the PeopleSoft Absence Management PeopleBook) expand on all of the above texts by providing approval workflow details that relate to delivered business processes.
The PeopleSoft PeopleBook: Approval Framework describes the common Approval Framework functionality that applies to all product families.
Before implementing, you should read all relevant sources of information to gain a complete understanding of how the pieces fit together.
See PeopleSoft 9.1 PeopleBook: Approval Framework.
PeopleSoft delivers many approval transactions that are already configured to work with the Approval Framework. 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 HCM transactions for use with the Approval Framework:
Register the approval transaction in the Approval Framework through the Register Transactions page.
Link Human Resources self-service transactions to the Approval Framework through the Workflow Transactions page.
Set up the configuration options for the approval transaction on the Configure Transactions page.
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:
Define the stages, paths, and steps of the approval process definitions on the Setup Process Definitions page.
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.
Set up path details for workflow approval processes on the Approval Path Definition page.
Define step details for approval workflow processes on the Approval Step Definition page.
Define dynamic approvals through various components.
Create email templates for the approval transaction on the Generic Template Definition page.
Maintain user list definitions for the approval transaction on the User List Definition page.
Set up the Notification and Escalation Manager.
Set up the appropriate permission lists, roles, and web libraries through PeopleTools security components.
If you need to implement other transactions for use with the Approval Framework 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 PeopleSoft PeopleBook: Approval Framework
PeopleSoft HCM 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 HCM custom navigation pages, the PeopleSoft application 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
PeopleSoft Applications User Guide
This table lists the custom navigation pages that are used to navigate in the setup and administrative components for approvals functionality:
Page Name |
Navigation |
Usage |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center |
Approval administrators and implementers can use the links on this page to access the components necessary to register and set up transactions for the Approval Framework for PeopleSoft HCM. |
|
Workforce Administration, Self Service Transactions, Approvals and Delegation |
Approval administrators can use the links on this page to access the components necessary to monitor and troubleshoot approval transactions and to maintain delegation and for PeopleSoft HCM. |
To register approval transactions, use the Register Transactions (EOAW_TXN) component.
This section provides an overview of the approval transaction registry, lists prerequisites, and lists the page used to register approval transactions.
The approval transaction registry is the interface that developers use to register a PeopleSoft application's transaction with the Approval Framework. 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 Framework. 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 Framework. 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 HCM delivers several approval transaction process identifiers that are common across applications for use with the Approval Framework. The system uses these process IDs specifically for registering delegation-related transactions with the Approval Framework 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 Framework on the Register Transactions page, you must specify a header record for the approval transaction. 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 HCM applications deliver:
Process ID |
Description |
AbsenceManagement |
Absence Management |
Absence_Mgmt_ByDeptManager |
Absence Management By Department Manager |
Absence_Mgmt_ByPosMgmt |
Absence Management By Position Management |
Absence_Mgmt_ByPosnDeptMgr |
Absence Management By Position - Department Manager |
Absence_Mgmt_ByPosnSupervisor |
Absence Management By Position - Supervisor |
Absence_Mgmt_BySupervisorId |
Absence Management By Supervisor ID |
Abs Mgmt - Leave Donations |
Leave Donations |
AM_Extended_Abs |
Extended Absence |
Delegation |
Defines delegation transactions for the Approval Framework. |
DelegationBatch |
Defines batch delegation transactions for the Approval Framework. |
DelegationNotifyAdmin |
Defines delegation transactions for the Approval Framework where the administrator gets notified. |
DelegationRevoke |
Defines revoked delegation transactions for the Approval Framework. |
JPMNonpersonProfiles |
Non-person Profile |
JPMPersonProfiles |
Person Profile |
JobOffer |
Job Offer |
JobOpening |
Job Opening |
PerformanceManagement |
Appraisal Transaction Approval |
PromoteEmployee |
Promotion Transaction Approval |
ReportingChgEmployee |
Reporting Change Transaction Approval |
TLPayableTime |
TL Payable Time Process ID |
TLReportedTime |
TL Reported Time Process ID |
TransferEmployee |
Transfer Transaction Approval |
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.
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
Implementation of HCM Transactions for Approval Framework
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_TXN |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Register Transactions, Register Transactions |
Register approval transactions in the Approval Framework by creating a unique approval process identifier for each approval transaction. The transaction definition is the metadata that describes the transaction setup to the Approval Framework. |
See Also
PeopleTools PeopleBook: PeopleCode Developer's Guide
To set up links to self-service transactions and approval functionality, use the Workflow Transactions (HCM_EO_TXN) component.
This section lists the page used to link workflow transactions and discusses how to link workflow transactions.
Page Name |
Definition Name |
Navigation |
Usage |
HCM_EO_TXN |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Workflow Transactions, Workflow Transactions |
Link self service transactions to the appropriate approval functionality, either the Approval Framework or the existing approval workflow functionality from previous releases. For transactions that use the Approval Framework, you must additionally specify the approval process ID associated with the transaction. You can also enable delegation of transaction initiation and approval. |
Access the Workflow Transactions page (Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Workflow Transactions, Workflow Transactions).
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.
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.
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. |
Select to enable delegation of transaction initiation for the corresponding self-service transaction that uses existing approvals configuration from a previous release. The transaction then becomes available for configuration as an initiate-type delegation transaction. Configure delegation transactions on the Configure Delegation Transaction page. |
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 and Delegation framework. The data that you enter into this grid links the transaction name and accompanying tables for HCM self-service transactions to the approval process IDs that you create for these transactions on the Register Transactions page as part of the Approval Framework setup.
Note. You can only list a particular transaction once. You cannot assign the same Approval Framework 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 Framework, you define a unique transaction registry ID, called a process ID, for each of your HCM 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 Framework, the self-service transactions can dynamically retrieve this approval process ID by transaction name and thus invoke the Approval Framework. The Approval Framework requires this parameter during processing. |
Select to enable delegation of transaction initiation for the corresponding self-service transaction that uses the Approval Framework. The transaction then becomes available for configuration as an initiate-type delegation transaction. Configure delegation transactions on the Configure Delegation Transaction page. |
|
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 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
To select and define elements that determine what triggers a notification, who receives the notification, and the content of the notification, use the Configure Transactions (EOAW_TXN_CONFIG) component .
This section lists the page used in configuring approval transactions.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_TXN_NOTIFY |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Configure Transactions, Configure Transactions |
Configure how the system uses the particular implementation of approval triggers by configuring all the events and notifications associated with your approval process IDs. For HCM transactions, the workflow engine requires that you enter specific values in the User Utilities section to enable it to interact with the Approval Framework and Delegations. 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 HCM 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. The Events 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. |
See Also
Configuring Approval Transactions
Defining Notification Templates for Approvals
PeopleTools PeopleBook: PeopleCode Developer's Guide
To set up approval process definitions, use the Setup Process Definitions (EOAW_PRCS) component.
Business analysts use this component 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.
See Setting Up Approval Framework Process Definitions.
This section list the pages used to set up approval process definitions and reviews an example of setting up the HCM approval process definition.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_PRCS_MAIN |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Setup Process Definitions, Setup Process Definitions |
Define workflow approval process stages. |
|
EOAW_CRITERIA |
|
Define criteria for workflow approval processes. Criteria definitions are used to define bits of logic that, at runtime, the Approval Framework evaluates for a Boolean result (true or false). 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:
|
|
EOAW_PATH_SEC |
Click the Details link or icon within the Paths group box on the Setup Process Definitions page. |
Set up path details for workflow approval processes. |
|
EOAW_STEP_SEC |
Click the Details icon within the Steps group box on the Setup Process Definitions page. |
Define step details for workflow approval processes. |
|
EOAW_PRCS_COPY |
Click the Clone Approval Process link on the Setup Process Definitions page. |
Create a new approval process definition by copying the existing one. The system requires that you assign a new definition ID and effective date. |
|
EOAW_PRV_MON_SRC |
Click the Preview Approval Process link on the Setup Process Definitions page. |
Verify the routing of the approval process definition by previewing. |
This section provides an example of how set up an approval process definition for a transaction that is specific to PeopleSoft HCM.
In this example, let's suppose that your 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 (Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Setup Process Definitions, Setup Process Definitions).
Setting up an approval process definition
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 Framework 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 you will add logic that the Approval Framework evaluates at runtime for a Boolean result. You can define criteria at the definition, path, or step level. For this example, you want to add logic to the definition level that instructs the Approval Framework 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 Setup Process Definitions page.
Defining processing criteria
On this page you will:
Select the Criteria Type field value User Entered.
This activates fields on the page that enable you to manually define your criteria.
Select the All Criteria Needed to Satisfy check box.
The system selects this check box by default.
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 Framework 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 Framework continues to search for another definition ID that matches the required criteria needed to process the transaction for the related approval process ID.
Next you want to require the Approval Framework 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.
Specifying a timeout option of three days
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, the Days field to 3, and click OK.
Now that you have defined the approval process definition, you can look at a graphic representation. Click the Approval Process Viewer link at the top of the Setup Process Definitions page.
Viewing the approval process definition
The Setup Process Definitions 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 you have decided that it is best that there is a third approval step for an absence request. Click the plus sign after step 2.
Adding an additional step from the Approval Process Viewer page
The system returns you to the Setup Process Definitions page and inserts a new row after step 2 for you to enter the new step. Click Save when you have completed your definition.
To set up dynamic approvals, use the Setup Process Definitions (EOAW_PRCS), Maintain User Lists (EOAW_USER_LIST), Roles (ROLEMAINT), and User Profiles (USERMAINT) components.
This section provides an overview of how to configure dynamic approval authorizations and lists the pages used to define dynamic approvals.
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.
To configure the dynamic approval authorization, the approvals administrator must:
Define user lists for dynamic authorizations through the User List Definition page.
The Approval Framework 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.
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 the Edit link for the Authorize option. Deselect the Hide from portal navigation check box, and click Save. Then navigate to PeopleTools, Portal, 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.
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:
Select Dynamic for a dynamic approval path in the Step Source field.
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.
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.
Select the Check Authorization check box to enable the approval authorization.
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.
For more information and an example of dynamic approvals see PeopleSoft PeopleBook: Approval Framework, "Defining Dynamic Approvals."
See Defining Dynamic Approvals.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_AUTH |
Set Up HRMS, Common Definitions, Approvals, Authorization, Approval Authorization Note. This page is available through PeopleTools but must be added to the portal navigation to render it available in the application. |
Authorize roles and approvers for dynamic paths. |
|
EOAW_PRCS_MAIN |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Setup Process Definitions, Setup Process Definitions |
Define workflow approval process stages. |
|
EOAW_CRITERIA |
|
Define criteria for workflow approvals. Criteria definitions are used to define bits of logic that, at runtime, the Approval Framework evaluates for a Boolean result (true or false). |
|
EOAW_PATH_SEC |
Click the Details link within the Paths group box on the Setup Process Definitions page. |
Set up workflow approval path details. |
|
EOAW_STEP_SEC |
Click the Details icon within the Steps group box on the Setup Process Definitions page. |
Define step details for approval workflow. |
|
EOAW_USER_LIST |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Maintain User Lists, User List Definition |
Create and maintain user-list definitions used for routing transactions for approval. Also, define user sources for use with steps in the approval process. |
|
ROLEDEFN |
PeopleTools, Security, Permissions & Roles, Roles |
Set up roles for workflow. See PeopleTools PeopleBook: Security Administration |
|
USER_GENERAL |
PeopleTools, Security, User Profiles, User Profiles, General |
Set up user IDs and assign roles. See PeopleTools PeopleBook: Security Administration |
To set up notification templates for approvals, use the Generic Templates (WL_TEMPLATE_GEN) component.
This section provides an overview of generic template definitions and list the pages used to define notification template definitions.
Anytime that the Approval Framework 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 Framework 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 Framework 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.
See Also
Defining Notification Templates and Users for Approval Framework
Reviewing Delivered Notification Templates for Delegation
Page Name |
Definition Name |
Navigation |
Usage |
WL_TEMPLATE_GEN |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Generic Templates, Generic Template Definition |
Enter generic template definitions. |
To set up users for approvals, use the User Profiles (USERMAINT) and Maintain User Lists (EOAW_USER_LIST) components.
This section provides an overview of user lists within Approvals and lists the pages used to define users for approvals.
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 Lists component.
PeopleSoft HCM delivers the following common user lists for use with the Approval Framework:
User List |
Description |
By Department Manager |
Uses the Manager ID field from the Department Profile page. |
By Partial Pos Mgmt - Dept Mgr |
Uses the Reports To field from the Job Information page and then the Manager ID field for that position and department from the Department Profile page. |
By Partial Pos Mgmt - Suprvsor |
Uses the Reports To field from the Job Information page and then the Supervisor ID field for that position from the same page. |
By Position Management |
Uses the Reports To field from the Job Information page. |
By Supervisor ID |
Uses the Supervisor ID field from the Job Information page. |
Note. Refer to the corresponding documentation in your application-specific PeopleBooks for information about delivered user lists that are specific to an application.
PeopleSoft HCM 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 Framework 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:
Application Class Path |
Related User List Definition |
HCSC_USERLISTS:GetApproversByPositionMgmt |
By Position Management |
HCSC_USERLISTS:GetApproversByDeptManager |
By Department Manager |
HCSC_USERLISTS:GetApproversByPosnDeptMgr |
By Partial Pos Mgmt - Dept Mgr |
HCSC_USERLISTS:GetApproversByPosnSupervisor |
By Partial Pos Mgmt - Suprvsor |
HCSC_USERLISTS:GetApproversBySupervisorId |
By Supervisor ID |
The delivered user lists correspond with different access types that PeopleSoft 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 HCM supports multiple job capability only in the predefined user lists that we deliver.
Note. PeopleSoft HCM does not support multiple job capability for these custom user lists.
See Also
PeopleTools PeopleBook: PeopleCode Developer's Guide
Page Name |
Definition Name |
Navigation |
Usage |
USER_ROLES |
PeopleTools, Security, User Profiles, User Profiles, Roles |
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. |
|
USER_WORKFLOW |
PeopleTool, Security, User Profiles, User Profiles, Workflow |
Define workflow for user profiles. 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. |
|
EOAW_USER_LIST |
Set Up HRMS, Common Definitions, Approvals, Approvals Setup Center, Maintain User Lists, User List Definition |
Create and maintain user-list definitions used for routing transactions for approval. Also, define user sources for use with steps in the approval process. Note. If you are using the Query option to define the user list for approval workflow, then, when you are creating the query in the Query Manager component, you must set the Query Type value of the query to Process. Setting the Query Type value to User can cause an error. |
To set up notification and escalation, use the Define Event Types (EOAW_NEM_EVENTS), Define Events (EOAW_NEM), Event Status (EOAW_NEM_STATUS), and Schedule JobSet Definition (SCHDLDEFN) components.
This section provides an overview of notification and escalation, list the pages used to set up the Notification and Escalation manager, and discusses how to view event statuses.
Notification and Escalation Manager (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.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_NEM_EVENTS |
Set Up HRMS, Common Definitions, Approvals, Notification and Escalation, Define Event Types, Define Event Types |
Associate events to a server. |
|
EOAW_NEM_SETUP |
Set Up HRMS, Common Definitions, Approvals, Notification and Escalation, Define Events, Define Events |
Set up an escalation event and define the evaluation and action details. |
|
EOAW_NEM_STATUS |
Set Up HRMS, Common Definitions, Approvals, Notification and Escalation, Event Status, Event Status |
View the status of an event. |
|
SCHDLDEFN |
PeopleTools, Process Scheduler, Schedule JobSet Definitions, Schedule JobSet Definition |
Set up a NEM to define the job to run, and how often you want it to run. See Setting Up a NEM. |
Access the Event Status page (Set Up HRMS, Common Definitions, Approvals, Notification and Escalation, Event Status, Event Status).
This Event |
Click to delete all notification event logs for the event ID that you selected. |
All Events |
Click to delete all notification event logs for all events. |
Notification Manager
DateTime Stamp |
Used in the Status record to track the results of each instance run. |
Matches |
Displays the number of rows that are returned from a row set. |
Detail |
Displays detailed status messages for each notification event. |
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:
Permission List Name |
Description |
Roles Attached To |
HCCPSCAW1010 |
This is the approvals administrator permissions list. It grants permissions for Approval Framework administration and configuration objects. These objects include all components under the menu path Set Up HRMS, Common Definitions, Approvals. PeopleSoft delivers this list already attached to the Approval Framework administrator role. You should also attach this permission list to any existing, application-specific administrator roles in your organization for which you want the administrators to inherit this permission list. |
|
HCCPSCAW1020 |
This is the manager permissions list. It grants permissions for Approval Framework manager objects. These objects include several manger-specific self-service pages. PeopleSoft delivers this list already attached to the manager role. Any of your application-specific users who are considered managers and have the manager role assigned to them will automatically inherit this permission list. |
|
HCCPSCAW1030 |
This is the employee permissions list. It grants permissions for Approval Framework employee objects. These objects include several employee-specific self-service pages. PeopleSoft delivers this list already attached to the employee role. Any of your application-specific users who are considered employees and have the employee role assigned to them will automatically inherit this permission list. |
PeopleSoft HCM 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 Approval Framework 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 Framework, you must grant permission lists full access to the WEBLIB_EOAW web library. PeopleSoft HCM delivers these two web libraries as part of the delivered Approval Framework permission lists.
To grant permission lists access to web libraries:
Navigate to PeopleTools, Security, Permissions & Roles. Permission Lists.
Select the permission list for which you want to grant access to web libraries.
On the Web Libraries page, insert a new row for the web libraries WEBLIB_PTAF and WEBLIB_EOAW.
For each web library, click the Edit link.
The system displays the Weblib Permissions page.
Click the Full Access (All) button to grant access to all functions, or complete the Access Permissions field to grant access to specific script functions.
Click OK.
Save the permission list.
Note. The Approval 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
PeopleTools PeopleBook: Security Administration
The approval monitor gives administrators a view into all approvals to which they have access, as well as the ability to take necessary actions on pending approvals.
This section provides overviews of approvals administration and discusses how to administer approvals.
See Also
(USF) Reviewing Federal Self-Service Transactions
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:
Allows the approvals administrator to reassign pending approvals to a new approver based on search criteria. |
|
Approve |
Allows the approvals administrator to act on behalf of the assigned approver. The approval is initiated for a specific user, wherever that user may be pending within a specific transaction. Once the administrator takes action, the approval resumes the approval process. |
Denial |
Allows the approvals administrator to act on behalf of the assigned approver. The denial is initiated for a specific user, wherever that user may be pending within a specific transaction. |
Allows the approvals administrator to add a reviewer or approver to a specific transaction 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. The approvals administrator can add or remove 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 on the Configure Transactions page, only the users within that list can be added as an ad hoc approver or reviewer. |
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 Framework 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 Framework notifies the application of significant approval-related events.
Header actions allow the transaction lines to be grouped together and processed as one unit.
You can reassign pending tasks to another approver, or an 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 Framework is set up for administrative reassignment and escalations only.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_ADM_MON_SRC |
Workforce Administration, Self Service Transactions, Approvals and Delegation, Administer Approvals, Monitor Approvals |
Approvals administrators can search on approval processes and perform mass reassignments. |
|
EOAW_ADM_MON_ACT |
Click the link for the approval step in the Modified column on the Monitor Approvals page. |
Approvals administrators can perform an action on a specific approval process. |
See Also
Access the Monitor Approvals page for a view of the approval process (Workforce Administration, Self-Service Transactions, Approvals and Delegation, Administer Approvals, Monitor Approvals).
For a complete description of this page, see PeopleSoft PeopleBook: Approval Framework, "Using the Approval Monitor."
See Using the Approval Monitor Search Page.
Approver's Oper ID (approver's operator ID) |
Select the operator ID of the approval to whom the approval transaction is assigned. |
Reassign To |
Select the operator ID of the person to whom you want to reassign approval transactions for the specified approver in the Approver's Oper ID field. |
Select to allow auto approval of approval transactions that are assigned to the specified approver. |
|
Select to allow the specified approver to approve transactions on their own behalf. |
|
Comment |
Enter a comment to describe the mass reassignment. The comment becomes part of the transaction itself. |
Reassign Selected |
Click to reassign the approval transactions from approver in the Approver's Oper ID field to the person specified in the Reassign To field. The system reassigns only the approval transactions that you have selected in the search results. |
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.
Select All |
Click to select all approval transactions that are listed in your search results. |
Deselect All |
Click to clear the selection of all transactions in your search results. |
Filter |
Specify key values and then click the Filter button to narrow your search results within an approval process section. |
Modified |
The system displays the date when the approval transaction was last modified. If the approval transaction has never been modified, the system displays Never. |
Status |
The system displays the status of the approval transaction: Pending, Denied, Terminated, or Approved. |
<Key Values> |
The system displays key values for each of the approval transactions that meet your search criteria. Key values vary depending on the approval process. |
This section provides an overview of the Approvals audit report, lists the page used to run the Approvals Audit Report, and discusses how to generate an approvals audit report.
The Approval Framework 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 Framework 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, 2009 to December 31, 20096, and a specific originating requester, then the system generates a report that includes all transactions requested by that person for 2009, 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 Name |
Definition Name |
Navigation |
Usage |
HCSCAWE_RUN_CNTL |
Workforce Administration, Self-Service Transactions, Approvals and Delegation, Approvals Audit Report, Approvals Audit Report |
Generate an approvals audit report that provides a complete list of approval transactions that have passed through the Approval Framework based on your run criteria. |
Access the Approvals Audit Report page (Workforce Administration, Self-Service Transactions, Approvals and Delegation, Approvals Audit Report, Approvals Audit Report).
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 approval 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 approval transaction requests that currently have the selected status. |
The following is a sample of the Approvals Audit Report:
Note. You can configure this report through the PeopleTools XML Publisher functionality.
This section lists the pages used to work with self-service approval transactions and 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 HCM product line. For details about self-service pages that are specific to business processes within an application, refer to application-specific PeopleBooks.
Page Name |
Definition Name |
Navigation |
Usage |
HCM_APPR_STATUS |
|
Manager and employees can view the status and details of approval transactions requests that are associated with them. |
|
HCM_JOB_SELECT |
The system displays this page when a user submits or approves an request and the user has multiple jobs. |
Users with multiple jobs can select the job for which they want to submit or approve an approval requests. |
See Also
Working with Self-Service Delegation
Access the Review Transactions page (Manager Self Service, Review Transactions, Review Transactions or Self Service, Review Transactions, Review Transactions).
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 Framework, PeopleSoft recommends using the PeopleTools Archive manager component.
Access the Select Job page (the system displays this page when a user submits or approves an request and the user has multiple jobs).
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.