people soft enterprise absence management 8.9 approval framework

PeopleSoft Enterprise Absence Management: Approval Framework

February 2006

PeopleSoft Enterprise Absence Management: Approval Framework

PeopleBooks Contributors: Teams from PeopleSoft Enterprise Product Documentation and Development.

Copyright © 2006, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are “commercial computer software” or “commercial technical data” pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Open Source Disclosure

Oracle takes no responsibility for its use or distribution of any open source or shareware software or documentation and disclaims any and all liability or damages resulting from use of said software or documentation. The following open source software may be used in Oracle’s PeopleSoft products and the following disclaimers are provided.

Apache Software Foundation

This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Copyright 1999-2000. The Apache Software Foundation. All rights reserved.

THIS SOFTWARE IS PROVIDED “AS IS'” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

OpenSSL

Copyright 1998-2003 The OpenSSL Project. All rights reserved.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

SSLeay

Copyright (C) 1995-1998 Eric Young. All rights reserved.

This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]). Copyright (C) 1995-1998 Eric Young. All rights reserved. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Loki Library

Copyright 2001 by Andrei Alexandrescu. This code accompanies the book: Alexandrescu, Andrei. “Modern C++ Design: Generic Programming and Design Patterns Applied”. Copyright (c) 2001. Addison-Wesley. Permission to use, copy, modify, distribute and sell this software for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation

Helma Project

mailto:[email protected]

Copyright 1999-2004 Helma Project. All rights reserved. THIS SOFTWARE IS PROVIDED “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE HELMA PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Helma includes third party software released under different specific license terms. See the licenses directory in the Helma distribution for a list of these license.

Sarissa

Copyright 2004 Manos Batsis

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

TABLE OF CONTENTS

Working with Approvals .................................................................................................................. 1 Understanding the Approval Process .......................................................................................... 1

Defining the Approval Process ........................................................................................... 4

Understanding the Approval Process Design..................................................................... 4

Pages Used to Modify the Approval Process ..................................................................... 5 Defining Approval Stages ................................................................................................... 6

Setting Up Approval Paths ................................................................................................. 9

Defining Approval Steps ................................................................................................... 10

Defining Approval Criteria................................................................................................. 12 Registering Approval Transactions .................................................................................. 14

Defining Approval Notifications......................................................................................... 17

PeopleSoft Proprietary and Confidential 1

Working with Approvals This document provides an overview of the approval process and the approval process design, and discusses how to define the approval process.

Understanding the Approval Process PeopleSoft Absence Management delivers six approval definitions:

• AbsenceManagement.

• Absence Mgmt ByDeptManager.

• Absence Mgmt ByPosMgmt.

• Absence Mgmt By PosnDeptMgr.

• Absence Mgmt ByPosnSupervisor.

• Absence Mgmt BySupervisorid.

When the originator of an absence request submits the entry, 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 Default Set ID fields on the Absence page will be left blank. 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 telling them there is an absence event needing their approval. The approver has to option of:

• Approving the absence event. The system sends a notification to the next person in the approval process, if one is indicated.

• Denying the absence event. The system ends the approval process. The originator of the absence event will receive notification indicating the absence event has been denied.

• Sending back the absence for rework. The system sends a notification to the requestor that such absence needs rework. The requestor can modify the absence and resubmit for approval.

If the system cannot identify the first approver, it moves to step two of the approval process.

The second step in the approval process is to identify the second person to approve the absence request, if one is indicated. If the system identifies the second approver, the system sends a notification to the approver telling them there is an absence event needing their approval. The second approver has the option of:

• Approving the absence event. The system updates the status of the absence event to approve and ends the approval process.

• Denying the absence event. The system ends the approval process. The originator of the


absence event will receive notification indicating the absence event has been denied.

• Pushback the absence event. 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 approval steps are not met or if the system is unable to identify the approver, the system automatically submits a notification to the approval administrator telling the administrator there is an absence event requiring their attention. The absence administrator can use the Monitor component to Approve or Deny an event.

This example shows how an administrator approves or denies and absence event:

Example of administrator approval page

The following diagram illustrates the approval process flow for a request with two levels of approvers:


An originatorcreates an

absence event.

A notification issent to the first

approver.

The first approverapproves or deniesthe absence event.

A notification issent to the second

approver.

Second approverapproves, denies, or

push backs theabsence event.

System assignsapproved status tothe absence event.

Approve

Approve

Deny

Deny

Pushback

Pushback

Absence request approval process flow with two levels of approvers


Note. The only delivered approval process with two approvers 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 process ID definition or modify the existing process ID definitions to add as many approval steps as needed.

Note. If your absence request does not require approval, then leave Approval Process ID and Default Set ID fields blank on the Absences page of the Country Take component. The absence request will be automatically approved once the user submits it.

See Also

PeopleSoft Enterprise Absence Management 8.9 PeopleBook, Setting Up Self Service Absence Transactions, “Defining Self Service Absence Rules by Take Element”

Defining the Approval Process To define the approval process, use the Approval Process (SAC_AW_PRCS) and the Approval Transaction Registry (SAC_AW_TXN) components.

This section provides an overview of the approval process design and discusses how to:

• Define approval stages.

• Set up approval paths.

• Define approval steps.

• Define approval criteria.

• Register approval transactions.

Understanding the Approval Process Design 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.

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

• Criteria.

Criteria defines the rules that are used by the approval process to determine if a stage or step is executed.

Pages Used to Modify the Approval Process

Page Name Object Name Navigation Usage Approval Process Definition

SAC_AW_PRCS_MAIN Set Up HRMS, Common Definitions, Approvals, Approval Process, Approval Process Definition

Define workflow approval stages.

Path SAC_AW_PATH Click the Path link on the Approval Process Definition page.

Set up approval paths.

Criteria Definition SAC_CRITERIA Click the Alert Criteria link on the Approval Process Definition page.

Define approval criteria.

Step SAC_AW_STEP Click the Step Details link on the Approval Process Definition page.

Define steps for workflow approvals.

Approval Transaction Registry

SAC_AW_TXN Set Up HRMS, Common Definitions, Approvals, Approval Transaction Registry, Approval Transaction Registry

Register approval transactions.

Approval Transaction Registry - Notification

SAC_AW_TXN_NOTIFY Set Up HRMS, Common Definitions, Approvals, Approval Transaction Registry, Approval Transaction Registry - Notification

Define approval notifications.


Defining Approval Stages Access the Approval Process Definition page.

Approval Process Definition page Admin Role (administrator role)

Select the user list role used by the approval process to route the transaction to all users filling that role. This is usually based on job function, not individual users. User lists are defined on the User List page.

Alert Criteria Click to access the Criteria Definition page where you can define user and field criteria along with application class criteria for this stage.

Take Action on Line Completion

Line level approvals are not used in HCM – this check box should be left blank.

User Auto Approval Select to enable the system to remember an approver’s action for this process. The next time this approval process is presented to the approver, the system automatically applies the approvers selections. The automatic application of steps in the process is left in place until you clear the User Auto Approval check box.


Stages

Stage Number Enter the sequence in which you want this stage of the approval acted upon. You can also enter a description for the stage in the Description field.

Paths

Approval Path Enter a value that identifies this path. A path is a sequence of steps. An example could be a department path when an absence requires approval up a department hierarchy. Within a stage, paths execute in parallel with each path inheriting its level from the stage to which it belongs. Path-entry criteria determines whether a path executes for a transaction thread. When a stage becomes active, approvers in the stage get pending work; all its contained paths become active simultaneously. All the paths of a stage queue work to approvers in parallel. The stage is complete only when all paths in it are complete. Each path has entry criteria associated with it. The purpose of this criteria is to determine whether or not that path should trigger for a particular transaction. If the system evaluates the criteria you enter for a path to be false for a transaction, then it bypasses the path for that transaction.

Step Source Select the method by which steps are instantiated during the approval process. Values are:

Static: Select this source to indicate that you want the system to use the individual user-defined steps when it processes an approval.

Dynamic: Select this step source to indicate that you want the system to use either a query or an application class when it processes an approval.

Path Details Click to access the Path page where you can define path criteria and escalation parameters, such as whether or not to notify the requester’s supervisor.

Criteria Click to access the Criteria Definition page where you can define user and field criteria along with application class criteria for this stage.

Steps

Step Enter the sequence in which you want this step performed during the approval process.


Approver User List Select the type of approver you want to use for this step. A user list is an entity that groups users in the system. Roles, queries, and application classes are examples of user lists. The system then uses the list and its users to run automated business processes. The list defines the user sources that can be used in approval steps.

Step Details Click to access the Step page where you can define approver requirements, self-approval details, and reviewers.



Setting Up Approval Paths Access the Approval Path Definition page.

Approval Path Definition page Approval Path Displays the path name that you are creating or updating.


Step Source Select the method by which steps are instantiated during the approval process. Values are:

Static: Select this source to indicate that you want the system to use the individual user-defined steps when it processes an approval.

Dynamic: Select this step source to indicate that you want the system to use either a query or an application class when it processes an approval. When you initialize the process, you select the query or class on which to base the approval. The system performs an iterative call to the query or class until the call does not return an approver. When using the Dynamic source, the system doesn’t consider criteria and user roles associated with an approval process. Instead, it uses the user list created by an application developer on which to initialize the process.

Skip Prior Steps for Requester

Select this check box to indicate that all approval steps in this path prior to the requester’s step are skipped.


Escalation Options

This feature is reserved for a future release.

Defining Approval Steps Access the Approval Step Definition – Step page.

Approval Step Definition page Step Number Enter the number for this step. It’s the sequence in which

an approval is routed. Each step typically represents a routing to an approver. However, it is possible to route to multiple approvers or reviewers in a step as well.


Approvers

Approver User List Select the type of approver you want to use for this step. You use a user list to map users to certain functional roles. The system then uses the list and its users to run automated business processes. The list defines the user sources that can be used in approval steps.


Approver Role Name Select a role that specifies the authority that a user has. The approval workflow engine filters approvers returned by the user list for this role. It also enforces the role at the time the approver acts. If there is a change in role, such as the approver is no longer in the role, the approver is blocked from acting on the absence event.

Approver Requirements

All Approvers Required Select to indicate that all approvers at this step are required to approve the requisition at this step. You can select to have all approvers or some approvers approve the requisition at this step.

Some Approvers Required Select to indicate that it is not required for all approvers to sign off on a requisition. If you select this option, you can define the number of approvers required in the Number of Approvers Needed field.

Number of Approvers Needed

Enter the minimum number of approvers you want to sign off for a requisition at this step. When an approval process is defined and this number is not met, the system notifies the system administrator.

Approver Requirements

This feature is reserved for a future release.

Reviewer User List

Reviewer User List Select the type of reviewer you want to use for this step. You use a user list to map users to certain functional roles. The system then uses the list and its users to run automated business processes. The list defines the user sources that can be used in approval and review steps.


Defining Approval Criteria Access the Criteria Definition page.

Criteria Definition page All Criteria Needed to Satisfy

Select this check box if you want all the criteria that you set up to be true before the system considers the rules to have been met.

User Entered Criteria

Description Enter a description for this set of criteria.


Field Criteria

Record Select a record that you want to use in defining approval criteria.

Field Name

Select a field you want to use to define approval criteria. The values you define in the remaining field criteria grid are those that are used in determining the approval criteria.

Criteria Operator Determines the action the system applies to the criteria you enter in the Value fields. The available options are:

Between: Use only values between the two values you enter as criteria.

Equals: Use only values equal to the entered criteria.

Greater Than: Use values equal to or greater than the entered criteria.

Is Blank

Is Not Blank

Less Than: Use any record value that is less than the value entered in the Criteria Operator field.

Not Equal To: Use any record value that is greater than or less than the entered criteria. Use any value that is not equal to the two values you enter as criteria.

Value Used to define a range upon which you want the Not Equal To or Between operators to apply.

Monetary Criteria

Absence Management does not use this section.

Application Class Criteria

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.


Registering Approval Transactions Access the Approval Transaction Registry page.

Approval Transaction Registry page (1 of 2)

Approval Transaction Registry page (2 of 2)


The approval transaction registry is the interface application developers use to register an application with the approval workflow engine. Transactions are processes that PeopleTools perform for applications. Transactions that require approvals are candidates for being linked to approval workflow engine. You use the Approval Transaction Registry page to link the components, event handler, records, and classes that you created into the approval process for an application transaction. Application developers register the main records and components that make up the transaction.

Approval Process ID Enter a name the system uses to track this approval workflow process for an absence event. 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 manage application specific transaction records and associate them with the approval process run time instances.

Approval User Info View (approval user information view)

Select the table from which you want to extract personal contact information for the approver. This is the information that appears when you use the approval status monitor to display personal information. These values are set up in the Application Designer.

Ad Hoc User List Define a user list to be used for additional adhoc approvers that are manually added to the approval process.

Enable Notifications Select this check box to have the Approval Engine send out email notifications.

Worklist Approval Component

Menu Name Select the menu name that contains the component you want the notification recipient to link to. This identifies where the person should go upon notification. If you do not enter values, the recipient is sent to the same menu and component that is defined for the worklist.

Approval Component Select the component on which the approval is going to be based. You must also create a URL to send to the job opening or job offer approval page for the job opening.

Approval Event Handler Class

Root Package ID Select the parent application class through which events are exposed. This defines the action to take based on events.


Path Select a path that uses a specific class within the root package.

AdHoc Approver Logic Class

PeopleSoft Enterprise Absence Management 8.9 does not use this functionality.

Transaction Approval Levels

Use this group box to define if the absence event is to be approved at the header or line level and what level the application supports. You define:

• The levels that are enabled by the application for approvals. The first row will always be the header level.

• The database table that represents this transaction level.


Defining Approval Notifications Access the Approval Transaction Registry – Notification page.

Approval Transaction Registry - Notification page

Events

Header or Line Level Defines whether the notification event is at the header or line level. All events in HCM are at the header level.

Event Select the event for which you want to send a notification. By default values, the approver is always notified of an event and when an error occurs the system notifies the requester and the system administrator. Event values include: Back, Complete, Error, Escalate, Launch, OnApprove, OnDeny, Reactivate, Reassign, Review, and Terminate.

Menu Name Select the menu name that contains the component you want to register for the Worklist. A menu is a collection of components that contain pages. The menu is the highest level in the hierarchy and you use the menu to access pages.

Approval Component Select the component on which the approval is going to be based. You must also create a URL to send to the requisition approval page for the requisition.

SQL Object Identifier (structured query language object identifier)

Select the object identifier you want to use to get content for the email.


Approval Participant Identify the participant that receives the notification. Values are: Approver, Dynamic, Requester, Administrator, User List, and Reviewer.

Notification Channel Identify the method of notification. Values are: None, Email, Worklist, or Both.

User List If Participant Type of User List is Selected this is the User List defined.

Template Name Select the template that is used to send the email. The delivered templates are:

• GP_ABS_SS_APPR

• GP_ABS_SS_APPR_READY

• GP_ABS_SS_DNY

• GP_ABS_SS_ERR

• GP_ABS_SS_SUB

• GP_ABS_SS_WRK

people soft enterprise absence management 8.9 approval framework

Documents