Professional Documents
Culture Documents
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.
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 (eay@cryptsoft.com). This product
includes software written by Tim Hudson (tjh@cryptsoft.com). 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
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
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
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.
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
• 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:
The following diagram illustrates the approval process flow for a request with two levels of
approvers:
A notification is
Pushback sent to the first Deny
approver.
Approve
Second approver
approves, denies, or
push backs the
absence event.
Approve
System assigns
approved status to
the absence event.
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”
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.
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.
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 Line level approvals are not used in HCM – this check box
Completion should be left blank.
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
Step Source Select the method by which steps are instantiated during
the approval process. Values are:
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.
Step Details Click to access the Step page where you can define
approver requirements, self-approval details, and
reviewers.
Criteria Click to access the Criteria Definition page where you can
define user and field criteria along with application class
criteria for this stage.
Criteria Click to access the Criteria Definition page where you can
define user and field criteria along with application class
criteria for this stage.
Step Source Select the method by which steps are instantiated during
the approval process. Values are:
Skip Prior Steps for Select this check box to indicate that all approval steps in
Requester this path prior to the requester’s step are skipped.
Criteria Click to access the Criteria Definition page where you can
define user and field criteria along with application class
criteria for this stage.
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 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 Enter the minimum number of approvers you want to sign
Needed 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
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.
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:
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
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.
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 Select the table from which you want to extract personal
(approval user information contact information for the approver. This is the
view) 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.
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.
Root Package ID Select the parent application class through which events
are exposed. This defines the action to take based on
events.
PeopleSoft Enterprise Absence Management 8.9 does not use this functionality.
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.
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.
SQL Object Identifier Select the object identifier you want to use to get content
(structured query language for the email.
object identifier)
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