Understanding the Approval Process in Time and Labor

Depending on your requirements, you can configure time approvals for the following options:

  • Reported time.

  • Payable time.

  • Both reported and payable time.

  • Overtime Requests

You can also set up email notifications for particular events. For managers, these include reported time needing approval, payable time needing approval, exceptions that have been generated, or a scheduled event that has been modified. For employees, email notifications include reported time which has been approved, payable time which has been approved, reported time which has been denied, or reported time which has been modified.

Note: Oracle PeopleSoft delivers Notification Composer Framework to manage the setup and administration of all notifications in one central location.

Once you have adopted the Notification Composer feature, you must use it to create new notifications and manage your existing notifications.

Notifications delivered with HCM Image 47 or later must use Notification Composer.

For more information about Notification Composer Framework, see Understanding Notification Composer.

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 Framework 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 Approval Framework 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: Workflow Technology describes the Approval Framework and application setup in full detail.

    It is the primary source of information for approval workflow.

  • This section expands on the PeopleTools section, describing the setup steps and details for the Approval Framework 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.

The following transactions in Time and Labor can require approval:

  • When an employee reports time.

  • When a manager or administrator reports time on behalf of the employee.

  • Time Administration generates payable time.

  • When an employee submits an overtime request.

This section discusses the several foundation elements of the Approval Framework, their definition, and how they are used for Time and Labor approvals and delegations. The following elements are discussed here:

  • Process ID

  • Header record

  • Definition ID

  • User list

  • Approval events and actions

Process IDs

A process ID is a unique approval process identifier for the approval transaction. Process IDs are registered in the Approval Framework transaction registry using the Register Transaction page. The process ID is passed to the Approval Framework when the Time and Labor application invokes the Application Framework application classes. Time and Labor provides the following process IDs:

  • TLReportedTime

  • TLPayableTime

  • TLOvertimeRequest

Header Record

After an approval process is defined, validated, and made active, the system can process a transaction for approval. Each PeopleSoft application typically has a top-level database record that distinguishes one transaction from the next. These top-level records are called header records. When a transaction is submitted for approval, the Approval Framework combines the approval process definition with the header record instance and line records, if line level approval is configured, to create a unique approval process instance. Time and Labor uses the following records as header records for approvals:

  • TL_RPTD_TIME for reported time approvals.

  • TL_PAYABLE_TIME for payable time approvals.

  • TL_OT_DATA for overtime request approvals

Definition ID

Each approval process ID can have one or more definition IDs for an approval transaction. The definition ID, with the other elements on the Setup Process Definitions page, enables the Approval Framework to determine which approval process ID to initiate, and determines the stage, path, and steps the approval process uses.

Time and Labor delivers the following definition IDs:

  • TLByDeptManager

  • TLByPosnDeptMgr

  • TLByPosnSupervisor

  • TLByPosMgmt

  • TLBySupervisorID

  • TLGroupSingleStageALL

  • TLGroupMultiStageSOME

  • TLGroupMultiStageALL

    Note: The TLGroupMultiStageALL Definition ID is not provided for the TLOvertimeRequest Process ID

Note: All delivered Time and Labor definition IDs use the TL Approval Administrator in the Admin Role, which is the role used by workflow to route the transaction to all users filling that role in case of an error during approval processing. The error conditions are no approvers or not enough approvers.

User List

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. The system routes approval transactions to these users, based on the step level definition created on the Setup Process Definitions page. Time and Labor user lists are based on either the delivered user lists for HCM or the Time and Labor group.

The user lists based on the delivered user lists for HCM are:

  • TLAdhocGroup

  • TLByDeptManager

  • TLByGroup1

  • TLByGroup2

  • TLByPosMgmt

  • TLByPosnDeptMgr

  • TLByPosnSupervisor

  • TLBySupervisor ID

You can use Time and Labor groups for approvals, whether you are using department security or Time and Labor group security, on the Static Group page (TL_GROUP_S1) or the Dynamic Group page (TL_GROUP_D1).

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 a reported time, payable time, or overtime waiting for approval. The approver has the option to:

  • Approve the time request. The system sends a notification to the next person in the approval process, if one is indicated.

  • Deny the time request. The system terminates the approval process. The originator of the time request receives a notification indicating that the time request has been denied.

  • Push back the time request. The originator of the time request receives a notification indicating that the time request needs their attention.

    Note: TL_UTILITY app package has two classes one under UserUtilities and the other for Web clock data. The package are called GetApproversByTLSecurity and GetApproversByDeptSecurity.

    All Time and Labor delivered approval definitions contain one step. The push back always goes back to the originator in Time and Labor.

Approval Definition and Approval Flow

The routing path of an approval request is be based on the approval stages, paths, and steps. These elements make up the Time and Labor process definitions, which are used for Time and Labor approvals. The process definition dictates:

  1. How the approval request proceeds from approver to approver.

  2. How many approvers must approve a request before it is routed to the next approver.

  3. If an approval request carried out in a parallel or sequential manner.

The following table describes the requirements and differences between the Time and Labor approvals definitions:

Definition ID

Approval Routing

Approver User List

Final Approval Status

TLByDeptManager

One stage, one path, and one step.

TLByDeptManager (assigned at step 1)

Approval by the specified manager required before the status of the request is Approved.

TLByPosnDeptMgr

One stage, one path, and one step.

TLByPosnDeptMgr (assigned at step 1)

Approval by the specified manager required before the status of the request is Approved.

TLByPosnSupervisor

One stage, one path, and one step.

TLByPosnSupervisor (assigned at step 1)

Approval by the specified supervisor required before the status of the request is Approved.

TLByPosMgmt

One stage, one path, and one step.

TLByPosMgmt (assigned at step 1)

Approval by PosMgmt required before the status of the request is Approved.

TLBySupervisorID

One stage, one path, and one step.

TLBySupervisorID (assigned at step 1)

Approval by the specified supervisor required before the status of the request is Approved.

TLGroupSingleStageALL

One stage, with two parallel paths that have one step in each path.

TLUserList1 (assigned at path 1/ step 1)

and

TLUserList2 (assigned at path 2/ step 1)

All approvers on path 1/ step 1 and all approvers on path 2/ step 1 must approve the request, before the status of the request is Approved.

Note: The approvers on path 2/ step 1 can approve the request at the same time as the approvers on path 1/ step 1.

TLGroupMultiStageSOME

Two sequential stages, each with one path and one step.

TLUserList1 (assigned at stage 1/ path 1/ step 1)

and

TLUserList2 (assigned at stage 2/ path 1/ step 1)

Some approvers on stage 1/ path 1/ step 1 must approve the request, and then some approvers on stage 2/ path 1/ step 1 must approve the request, before the status of the request is Approved.

Note: The approvers on stage 2/ path 1/ step 1 cannot approve the request before the approvers on stage 1/ path 1/ step 1 approve the request.

TLGroupMultiStageALL

Two sequential stages, each with one path and one step`.

TLUserList1 (assigned at stage 1/ path 1/ step 1)

and

TLUserList2 (assigned at stage 2/ path 1/ step 1)

All approvers on stage 1/ path 1/ step 1 and all approvers on stage 2/ path 1/ step 1 must approve the request, before the status of the request is Approved.

Note: All of the approvers on stage 1/ path 1/ step 1 must approve the request before any of the approvers on stage 2/ path 1/ step 1 can approve the request.

See Understanding Approvals.

Configuring Approval Transactions

PeopleSoft delivers the following events and email notification templates for configuring approval transactions for time and Labor:

Event

Template Name

Description

On Final Approval

HC_TL_EE_REP_APPROVED

HC_TL_EE_PAY_APPROVED

HC_TL_EE_OT_APPROVED

Reported time is approved, requestor notified.

Payable time is approved, requestor notified.

Overtime request is approved, requestor notified.

On Final Denial

HC_TL_EE_REP_DENIED

HC_TL_EE_PAY_DENIED

HC_TL_EE_OT_DENIED

Reported time is denied, requestor notified.

Payable time is denied, requestor notified.

Overtime request is denied, requestor notified.

Push Back

HC_TL_MGR_REP_PUSH_BACK

HC_TL_MGR_PAY_PUSH_BACK

HC_TL_MGR_OT_PUSH_BACK

Reported time is pushed back, approver notified.

Payable time is pushed back, approver notified.

Overtime request is pushed back, requestor notified.

Route for Approval

HC_TL_MGR_REP_AWAITING

HC_TL_MGR_PAY_AWAITING

HC_TL_MGR_OT_AWAITING

Reported time is awaiting approval, approver notified.

Payable time is awaiting approval, approver notified.

Overtime request is awaiting approval, approver notified.

Route for Review

HC_TL_MGR_REP_REVIEW

HC_TL_MGR_PAY_REVIEW

HC_TL_MGR_OT_REVIEW

Reported time is awaiting review, approver notified.

Payable time is awaiting review, approver notified.

Overtime request is awaiting review, approver notified.

On Error

HC_TL_ADMIN_ERROR

An error occurred while processing this request, admin is notified.

Note: It is noted that the approval process will look at the Position manager as long as Employee job data is associated with a Position number and approvals will be routed to Department manager when there is no Position number mentioned on Job data page. So if the employee does not have Reports To position number mentioned on Job data page, then the system will look at Position data to find the Report To.

See

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 Time and Labor Self Service applications. You might be able to modify this set up if you have a thorough understanding of the Approval Framework, PeopleCode and Time and Labor Self-service.

These steps are prerequisites to setting up and using approvals and delegations in Time and Labor.

Step 1

Define your URL for the URL Identifier TL_APPROVALS on the URL Maintenance page (PeopleTools > Utilities > Administration > URLs).

See PeopleTools 8.52: System and Server Administration PeopleBook, Using PeopleTools Utilities

Step 2

Set the workflow defaults on the Worklist System Defaults page (PeopleTools > Workflow > Defaults & Messages > Set Workflow Defaults).

Note: You must recycle and clear the cache on the application server for your changes to take effect.

See PeopleTools 8.52: Workflow Technology PeopleBook, Administering PeopleSoft Workflow

Step 3

Specify the user profile attributes for each user in the User Profiles component (PeopleTools > Security > User Profiles > User Profiles). Including the following:

  • Defining an email address for each approver on the User Profiles - General page.

  • Select the Routing Preferences on the Workflow page.

  • Establish the user profiles taking the following roles into consideration:

    • AWE Administrator

      This role provides access to the Approval Framework configuration and administration components.

    • AdhocUser_Role

      This role provides access to the ROLE_MANAGER for an ad hoc approver or reviewer.

    • EOAW_ADMINISTRATOR

      This role is the default role for Enterprise Components Approval Framework.

    • TL Approval Administrator

      This role provides access to the CAPTURE_TIME_AND_LABOR, EOAW_APPROVAL_WORKFLOW, and ROLE_MANAGER roles to set up and manage Time and Labor approvals.

    • Worklist Administrator

      This role receives worklist processes that have timed-out.

    • HCM Delegation Admin

      This role accesses all of the Delegation Administrator's delegation components.

See the product documentation for PeopleTools: Security Administration.

Step 4

Define the SMTP settings for the application server and the process server.

See the product documentation for PeopleTools: System and Server Administration.