You are on page 1of 23

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 (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

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

PeopleSoft Proprietary and Confidential 1


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:

PeopleSoft Proprietary and Confidential 2


An originator
creates an
absence event.

A notification is
Pushback sent to the first Deny
approver.

The first approver


approves or denies
the absence event.

Approve

Pushback A notification is Deny


sent to the second
approver.

Second approver
approves, denies, or
push backs the
absence event.

Approve

System assigns
approved status to
the absence event.

Absence request approval process flow with two levels of approvers

PeopleSoft Proprietary and Confidential 3


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.

PeopleSoft Proprietary and Confidential 4


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 SAC_AW_PRCS_MAIN Set Up HRMS, Common Define workflow approval
Definition Definitions, Approvals, Approval stages.
Process, Approval Process
Definition
Path SAC_AW_PATH Click the Path link on the Set up approval paths.
Approval Process Definition
page.
Criteria Definition SAC_CRITERIA Click the Alert Criteria link on Define approval criteria.
the Approval Process Definition
page.
Step SAC_AW_STEP Click the Step Details link on Define steps for workflow
the Approval Process Definition approvals.
page.
Approval Transaction SAC_AW_TXN Set Up HRMS, Common Register approval
Registry Definitions, Approvals, Approval transactions.
Transaction Registry, Approval
Transaction Registry
Approval Transaction SAC_AW_TXN_NOTIFY Set Up HRMS, Common Define approval
Registry - Notification Definitions, Approvals, Approval notifications.
Transaction Registry, Approval
Transaction Registry -
Notification

PeopleSoft Proprietary and Confidential 5


Defining Approval Stages
Access the Approval Process Definition page.

Approval Process Definition page


Admin Role (administrator Select the user list role used by the approval process to
role) 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 Line level approvals are not used in HCM – this check box
Completion 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.

PeopleSoft Proprietary and Confidential 6


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.

PeopleSoft Proprietary and Confidential 7


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.

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

PeopleSoft Proprietary and Confidential 8


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.

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:

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 Select this check box to indicate that all approval steps in
Requester this path prior to the requester’s step are skipped.

PeopleSoft Proprietary and Confidential 9


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.

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.

PeopleSoft Proprietary and Confidential 10


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

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.

PeopleSoft Proprietary and Confidential 11


Defining Approval Criteria
Access the Criteria Definition page.

Criteria Definition page


All Criteria Needed to Select this check box if you want all the criteria that you
Satisfy 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.

PeopleSoft Proprietary and Confidential 12


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.

PeopleSoft Proprietary and Confidential 13


Registering Approval Transactions
Access the Approval Transaction Registry page.

Approval Transaction Registry page (1 of 2)

Approval Transaction Registry page (2 of 2)

PeopleSoft Proprietary and Confidential 14


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

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.

PeopleSoft Proprietary and Confidential 15


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.

PeopleSoft Proprietary and Confidential 16


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 Select the object identifier you want to use to get content
(structured query language for the email.
object identifier)

PeopleSoft Proprietary and Confidential 17


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

PeopleSoft Proprietary and Confidential 18

You might also like