This chapter provides an overviews of the approval process, approval workflow, the configuration of approval transactions, and the approval process design.
Many daily tasks are part of a larger process that involves several steps and people working together. The term workflow refers to this process, which could encompass, for example, the approval of a time-off request. To facilitate this type of multiuser process, PeopleSoft can automatically trigger workflow notifications to inform the next approver in the process of work waiting.
The Approval Workflow Engine (AWE) is the engine that provides capabilities for creating, running, and managing the approval processes. The engine uses a series of database objects combined with application component configuration settings to determine how to process approvals using workflow.
The AWE is a common component that is shared across multiple PeopleSoft applications both within HCM and other application families. Due to the widespread use of this engine, you'll find documentation pertaining to it in various locations:
PeopleTools 8.52: Workflow Technology PeopleBook describes the AWE and application setup in full detail.
It is the primary source of information for approval workflow.
This present chapter expands on the PeopleTools chapter, describing the setup steps and details for the AWE that are specific to the HCM application line.
Application-specific HCM PeopleBooks expand on all of the above texts by providing approval workflow details that relate to specific business processes.
Before implementing, you should read all relevant sources of information to gain a complete understanding of how the pieces fit together.
See Setting Up and Working with Approvals.
Absence Management delivers six Approval Processes IDs:
AbsenceManagement.
Absence Mgmt ByDeptManager.
Absence Mgmt ByPosMgmt.
Absence Mgmt By PosnDeptMgr.
Absence Mgmt ByPosnSupervisor.
Absence Mgmt BySupervisorid.
Note. Multiple Approval Definition IDs can be added to an Approval Process ID. You can link multiple approval scenarios. One may be self-approved; while another can be one, two or more levels of approvals using approvers in one or in multiple user lists to a single Approval Process ID. This functionality allows you simplifying your approval scenarios and reduce the maintenance to multiple Approval Process IDs.
When the originator of an absence event submits the request, the system checks to see if approvals are being used based on the Administrative Rules defined on the Self Service – Country Take table - Absences page. If no approvals are needed then the Approval Process ID and Approval Definition ID fields on the Absence page will be left blank, or you can set up your own Approval Definition ID to make your events self and auto-approved. If values are entered for these fields the approvals process is initiated.
The first step in the approval process is to identify the first person to approve the transaction. This person is based on the Approval Process definition. If the system identifies this person, the system sends a notification indicating that there is an absence awaiting for approval. The approver has the option to:
Approve the absence. The system sends a notification to the next person in the approval process, if one is indicated.
Deny the absence. The system terminates the approval process. The originator of the absence will receive notification indicating the absence has been denied.
Push back the absence. The originator of the absence will receive a notification indicating the absence needs their attention.
Note. Push Back is a valid action for the approver before the absence has gone through the first approver in the approval path. Once the second or subsequent approver has pushed back the absence, the first approver should deny it instead of pushing back the absence. It is recommended for the first approver to always state the reason in the comment field when denying an absence.
If the system cannot identify the first approver, it moves to step two of the approval process.
A subsequent step in the approval process (if multiple levels of approvals were defined) is to identify the next person to approve the absence, if one is indicated. If the system identifies the next approver, the system sends a notification to the approver telling them there is an absence needing their approval. The next approver has the option of:
Approving the absence. The system updates the status of the absence event to approve and ends the approval process.
Denying the absence. The system ends the approval process. The originator of the absence event will receive notification indicating the absence event has been denied.
Push back the absence. The system sends a notification to the first approver associated with the absence event and notifies that person that the absence event needs their attention.
If neither approval steps are met, the system automatically submits a notification to the approval administrator telling the administrator there is an absence event requiring their attention.
The following diagram illustrates the approval process flow:
Absence Request Approval Process Flow
Note. The only delivered approval process with two levels of approval is the AbsenceManagement approval process ID. The others only have one level of approval. If the delivered approval processes do not meet your organizational needs you can create your own approval process ID, or add more steps to any of the approval definitions IDs that better fits your company policies.
PeopleSoft delivers the following events and email notifications templates for configuring approval transactions for Absence Management:
Event |
Template Name |
On Final Approval |
GP_ABS_SS_APPR |
Push Back |
GP_ABS_SS_WRK |
On Final Denial |
GP_ABS_SS_DNY |
On Error |
GP_ABS_SS_ERR |
On Process Launch |
GP_ABS_SS_SUB |
Route for Approver |
GP_ABS_SS_APPR_READY |
On Terminate |
GP_ABS_SS_WRK |
Note. These templates are delivered. If modifications are needed refer to the Applications Fundamentals Documentation. The events delivered must not be modified to ensure the correct functioning of the Absence Self Service applications. You might be able to modify this set up if you have a thorough understanding of the Approval Workflow Engine, PeopleCode and Absence Self-service.
See Also
Configuring Approval Transactions
The approval process consists of stages, paths, steps, user lists, and criteria.
Stages
Stages are the high level actions that the approval process executes in a specific order. Stages are made up of one or more paths.
AbsenceManagement, Absence Mgmt ByDeptManager, Absence Mgmt ByPosMgmt, Absence Mgmt By PosnDeptMgr, Absence Mgmt ByPosnSupervisor, and Absence Mgmt BySupervisorid use one stage.
Criteria
Criteria defines the rules that are used by the approval process to determine if a stage or step is executed.
Paths
A path is a sequence of steps.
AbsenceManagement, Absence Mgmt ByDeptManager, Absence Mgmt ByPosMgmt, Absence Mgmt By PosnDeptMgr, Absence Mgmt ByPosnSupervisor, and Absence Mgmt BySupervisorid use one path.
Steps
A step represents one or more persons assigned to approve or review the absence event. Steps within a path execute in sequence with separate criteria for each step that determines whether or not that step executes.
User Lists
User lists identify the people that are to act on an absence event. User lists can be roles, SQL definitions, queries, or application classes.
AbsenceManagement uses the AbsenceBySupervisorId user list.
Absence Mgmt ByDeptManager uses the AbsenceByDeptManager user list.
Absence Mgmt ByPosMgmt uses the AbsenceByPosMgmt user list.
Absence Mgmt By PosnDeptMgr uses the AbsenceByPosnDeptMgr user list.
Absence Mgmt ByPosnSupervisor uses the AbsenceByPosnSupervisor user list.
Absence Mgmt BySupervisorid uses the AbsenceBySupervisorId user list.
Note. To define the approval process, use the Setup Process Definitions (PTAF_PRCS) and the Register Transactions (PTAF_TXN) components.