recruiting

1. Understanding and Using Life Event Checklists in Oracle HRMS R12 (Doc ID
740618.1)
To
Bottom
In this Document
Abstract
History
Details
Set Up Steps
Managing Checklists
Set up Performers in AME
Background Processing
Allocating Checklist Tasks using an API
Using Allocated Checklists Window in the Professional User Interface (PUI)
Accessing Ex-Employees in the Allocated Checklists window
Troubleshooting
References
APPLIES TO:
Oracle Human Resources - Version 12.0.0 and later
Information in this document applies to any platform.
Relevancy checked - 09-Sep-2014
ABSTRACT
This document provides a technical and functional appreciation of the Life Event
Driven Checklist functionality available from Release 12 of Oracle HRMS, to be differentiated
from the checklist items that can be configured in People Management templates
(see Note:744150.1). It includes a step by step approach to the setup, and seeks to explain what
is happening in the background to further the reader's understanding of the process.
HISTORY

2. Author : Steve Cooper
Create Date 01-Oct-2008
Update Date 09-Sep-2014
Expire Date
DETAILS
Introduction
In the field of Human Resource Management certain events that happen during the lifetime of a
person on the system will require that a set of tasks are actioned as a result. Such events might
include Hiring an Employee, Termination, or Transfer, each of which would have an associated
'to do' list. Consider the following:
Event Checklist Tasks
Hire Adminstration Create Internal username/passwords
Order IT equipment
Allocate mentor
Mentoring Plan Introduce to colleagues
Induction Training (itemise)
Specialist Product Training (itemise)
Termination Redundancy Job Counselling
Initiate notice period
Disable username/passwords
The Checklist and tasks would be allocated to an employee after the triggering of a Life Event.
Performers can be assigned automatically or manually to each task, which can be monitored by
manager and employee for progress.
These Checklists need to be differentiated from the existing checklist functionality which is used
to monitor sign-off items in People Management (See Note:744150.1).
Set Up Steps
The allocation of tasks to an employee is dependent on two things
 The triggering of a Life Event that has been associated with the Checklist
 The eligibility profile assigned to an individual task.
A Life Event must be defined and linked to a Checklist, and Oracle Advanced Benefits (OAB)
must be installed in order to create a Life Event with Defined Person Changes. So a full install
of OAB is a mandatory prerequisite to using Life Event Checklists.
Furthermore, Checklists are limited to Employee person types as OAB does not process Life
Events for Contingent Workers or Applicants, neither does the Eligibility Profile pick up those
person types.
1. Create Checklist Life Event

3. General Definitions -> Additional Setup -> Life Event Reasons
Form Name - BENLEVRS ; Function Name - BENLEVRS
Create a new Life Event with the type of Checklist, and click on Person Changes button. If there
is an existing person change defined that you can use, choose it from the LOV on Name,
otherwise click on Define Person Change to specify the event that will trigger the allocation of
your checklist tasks. For example, the following will detect that a New Employee has been
entered by establishing if a new period of service has been created:
Table Name - PER_PERIODS_OF_SERVICE
Column Name - DATE_START
Old Value - No Value
New Value - Any Value
2. Create Eligibility Profile (Optional)
By Defining Eligibility Profiles you can tailor the tasks in a checklist to suit particular groupings.
For instance, some tasks may only be applicable to people in a particular location. Others to
people in a particular organization. If no eligibility profile is defined then all people are eligible
once the Life Event is processed. The Eligibility Profiles form used must be the one available
under the Work Structures -> Checklists menu as the 'Applies To' field defaults to a Checklist
Profile, as opposed to a Benefits Profile.
Navigate to Work Structures > Checklists -> Eligibility Profiles
Form Name - BENELPRO ; Function Name - BENELPRO_CHECKLIST
For example, to create an eligibility profile that is only applicable to employee assignments in a
particular location:
Header
Name - London Employees
Assignment Type - Employee Assignment Only
Applies To - Checklist Profile
Status - Active
Employment Tab
Work Location from dropdown menu
Seq - 1
Work Location - London
3. Create Additional Checklist Categories (Optional)
There are two seeded checklist categories,

4.  On-Boarding (recruitment, hiring, orientation,etc)
 Off-Boarding (termination, relocation, long term sickness,etc)
Additional categories can be created by extending the lookup type,CHECKLIST_CATEGORY.
Navigate to Other -> Application Utilities Lookups
4. Create Descriptive Flexfields (Optional)
There are two Descriptive Flexfields which can be used to provide additional context
information on Allocated Checklists and Tasks if required.
 Additional Allocated Checklist Details - Base
table(PER_ALLOCATED_CHECKLISTS. You could set up this DFF to display
segments specific to the defined Checklist.
 Additional Allocated Task Details - Base table(PER_ALLOCATED_TASKS).
You could set up this DFF to display segments specific to the defined tasks
5. Create Checklists and Tasks
The Checklists and Tasks are defined in the Setup/Maintain Checklists function.
Navigate to Work Structures > Checklists -> Setup/Maintain Checklists
Use Add Checklist to create a checklist against a specific category. Define a name and link in the
Life Event created in step 1)
Then use Add Task to create tasks associated to your checklist. Define a name, duration and
mandatory flag. Link in an eligibility profile if required (see step 2), and an AME identifier if a
performer is to be assigned automatically to the task when it is allocated (see below for further
information on setting up AME). Alternatively a performer can be allocated manually in the
Allocated Checklists function in Self Service.
6. Run Allocate Checklists and Tasks Program
This program should be scheduled at intervals regular enough to cater for the frequency of
occurring Life Events. When the Allocated Checklists function is run in Self Service the program
is run in background for the individual person to ensure the information displayed is current ,but
it's better to remove the overhead by scheduling this concurent program.
The program identifies pending Life Events linked to Checklists, and allocates the checklist tasks
to the person based on eligibility profiles.
Navigate to Processes and Reports - > Submit Processes and Reports.

5. N.B. The program must have first been added to the reports Request Set.
Program Name - Allocate Checklists and Tasks Process (executes pl/sql procedure
per_checklist_events.allocate_tasks)
Managing Checklists
Managers can view and update the tasks allocated to the employees reporting to them, and
employees can view, and update their own allocated tasks. For employees, add the function
HR_ALLOCATED_CHECKLIST_SS to their Self Service menu if not already there, and for
Managers, the function is HR_ALLOCATED_CHECKLIST_MGR_SS to get access to the
Allocated Checklists page.
The attributes of the tasks can be maintained here, including completion status, duration
,performer and flexfield information. Tasks can also be deleted, and added to the employee.
The checklist and tasks are allocated by the Allocate Checklists and Tasks Process. It should be
noted, however, that subsequent changes to the checklist are not re-allocated to employees who
have already received the checklist and tasks when the Life Event is triggered. If a task has been
added since the allocation, the task can be added manually to each employee using the Allocated
Checklists page, or by running the per_checklist_events.allocate_person_tasks procedure
(See Allocating Checklist Tasks using an API section).
Set up Performers in AME
Performers can be automatically assigned to designated checklist tasks by setting up an Approval
Group within Oracle Approvals Management (AME). This section will provide some basic steps
on how to do this, but for a more detailed understanding of using AME and Workflow
Notifications, see the Oracle Approvals Management Implementation Guide, and Oracle
Workflow Administrator and Users Guides.
1. Assign Roles and Grants
Before attempting to set up AME, checklist approval requirements must be well-planned in
advance, and the user with the responsibility for setting this up should be assigned the AME
Roles and grants. Follow instructions in Note 375119.1. AME has implemented Role Based
Access Model (RBAC), so do not attempt to assign the AME Responsibilities directly to your
user as you will not be able to select any transaction types using the AME Dashboards as a
consequence.
2. Create Conditions, Approval Group and Rule
 From Business Analyst Dashboard, select CHECKLIST transaction type

6.  Click on Conditions link, and click on Create button. Select CHECKLIST_ATTRIBUTE
and enter a name in the 'String Value' field in the region below. This will be the
Approvals Identifier for linking to the checklist task. See step 5 in Setup Steps above.
 Create Approval Group by selecting the tab 'Approver Groups'. Set usage type to Static,
and voting method to 'First Responder wins', and add group members as required.
 Associate the Action Type, 'Approval-Group Chain of Authority' to the CHECKLIST
Transaction Type.
 Select 'Rules' tab to define an AME Approval Rule of type 'List Creation', and associate
with your condition and action type.
 Finish the process to save the AME rule.
3. Update Checklist Task
In Setup/Maintain Checklists under Work Structures -> Checklists menu, update each required
task with the Approvals Identifier. This sets the columnAME_ATTRIBUTE_IDENTIFIER on
the table PER_TASKS_IN_CHECKLIST to the AME condition you have created. If different
performers required for each task, more than one condition may be required.
4. Respond to Notifications
When set up, the performer will default against the allocated tasks. A notification will be sent to
each member of the Approval Group saying,'Action Required: Complete <task name> for
<employee name>', and include two buttons, COMPLETED and NOT COMPLETED.
Whichever person responds to these buttons first will set the status on the task to
either Completed or Rejected. The Notification to all performers will then show 'FYI:
<employee name> task <task name> is updated'
Please note that Checklists use the parallel approval process which means that on initial
allocation the first approver in the list is selected for display in the 'Allocate Tasks' page.
Background Processing
1) Life Events
Checklist Life Events can be queried using the following statement
select LER_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, NAME
, BUSINESS_GROUP_ID, TYP_CD from BEN_LER_F where typ_cd='CHECKLIS
T';
For Example
LER_ID EFFECTIVE_START EFFECTIVE_END NAME BG TYPE ------ ------------
--- ------------- -------------------- -- -------- 41775 01-JAN-08 31-DEC-
12 New Hire (Checklist) 7269 CHECKLIST
2) Checklists
Example query of Checklist definition :

7. col name format a30 col checklist_category format a10
select CHECKLIST_ID, NAME, CHECKLIST_CATEGORY, EVENT_REASON_I
D from PER_CHECKLISTS where BUSINESS_GROUP_ID=7269;
Example Without Life Event Reasonlinked
CHECKLIST_ID NAME CATEGORY EVENT_REASON_ID
------------------ ------- -------------- ------------------------
61 Mentoring Period (UK) ONBOARD
Example With Life Event Reasonlinked
CHECKLIST_ID NAME CATEGORY EVENT_REASON_ID
------------------ ------- -------------- -------------------------
61 Mentoring Period (UK) ONBOARD 41775
3) Checklist Tasks
Example query of individual tasks:
col checklist_task_name format a30 col mandatory_flag a1 col target_duration_uom
format a1
select
TASK_IN_CHECKLIST_ID, CHECKLIST_TASK_NAME, ELIGIBILITY_PROFILE_ID,
MANDATORY_FLAG, TARGET_DURATION, TARGET_DURATION_UOM, TAS
K_SEQUENCE from PER_TASKS_IN_CHECKLIST where CHECKLIST_ID=61;
TASK_IN_CHECKLIST_ID CHECKLIST_TASK_NAME ELIG_PROF_ID M DURATION UOM ------
-------------- ------------------------------ ------------ - -------- --- 81 EDP New
Hire Plans 20433 Y 1 W 82 HRMS Troubleshooting Sessions 20433
Y 2 D 62 Orientation 20433 Y 1 W
4) Processing a Life Event
The Benefits model has been adapted so that whenever a Checklist Life Event is triggered, the
following procedure is called by the ben_create_ptnl_ler_for_per (bencrler.pkb) package:
PER_CHECKLIST_EVENTS.CREATE_EVENT
(p_effective_date => p_effective_date
,p_person_id => p_person_id
,p_assignment_id => p_assignment_id
,p_ler_id => p_ler_id
);
This creates a row in the table PER_BEN_IDENTIFIED_EVENTS.
For example
select BEN_IDENTIFIED_EVENT_ID, EVENT_REASON_ID, PERSON_ID,
STATUS, EFFECTIVE_DATE from PER_BEN_IDENTIFIED_EVENTS;

8. BEN_IDENTIFIED_EVENT_ID EVENT_REASON_ID PERSON_ID STATUS EFFECTIVE_DATE ----------
------------- --------------- ---------- ------ --------------
61 41775 29722 Pending 22-SEP-08
This row is the driver for allocating tasks to employees.
5) Allocating Tasks to Employees
The concurrent program, Allocate Checklists and Tasks, runs the procedure
per_checklist_events.allocate_tasks. This checks for rows on
PER_BEN_IDENTIFIED_EVENTS with a status of Pending. If it finds any, it will create rows
on the two tables PER_ALLOCATED_CHECKLISTS and PER_ALLOCATED_TASKS.
col checklist_name format a30 col checklist_category format a10
select ALLOCATED_CHECKLIST_ID, CHECKLIST_ID, PERSON_ID, ASSIGNMEN
T_ID, CHECKLIST_NAME, CHECKLIST_CATEGORY from PER_ALLOCATED_CHECKLISTS
where CHECKLIST_ID=61
ALLOCATED_CHECKLIST_ID CHECKLIST_ID PERSON_ID CHECKLIST_NAME CATEGORY --------
-------------- ------------ ---------- -------------- -------
- 21 61 29722 Mentoring Period (UK) ONBOARD
select ALLOCATED_TASK_ID, ALLOCATED_CHECKLIST_ID, TASK_NAME,
PERFORMER_ORIG_SYS_ID PERFORMER, TASK_OWNER_PERSON_ID TASK_OWNER from PER_A
LLOCATED_TASKS where ALLOCATED_CHECKLIST_ID = 21;
ALLOCATED_TASK_ID ALLOCATED_CHECKLIST_ID TASK_NAME PERFORMER TAS
K_OWNER ----------------- ---------------------- -------------------- -----
---- ---------
- 21 21 Orientation 29498 2
7655 22 21 New Hire Program 23
21 HRMS Troubleshooting Sessions
The table PER_BEN_IDENTIFIED_EVENTS has status changed to Processed.
BEN_IDENTIFIED_EVENT_ID EVENT_REASON_ID PERSON_ID STATUS EFFECTIVE_DATE ----------
------------- --------------- ---------- ------ -------------
- 61 41775 29722 Processed 22-SEP-08
Allocating Checklist Tasks using an API
When setting up checklists, it may be necessary to do a manual allocation because some
employees have already experienced the Life Event that has been defined. For instance, if the
Life Event is triggered for new employees, and several were entered onto the system prior to the
Life Event being defined and linked to the Checklist. In these circumstances the
per_checklist_events.create_event procedure can be called directly. The example shown passes
the parameters directly but it can be incorporated into a loop where the target person_ids are
passed in with the target start dates.
DECLARE
v_error varchar2(4000);
l_target_start_date date := to_date('01-Oct-2008','dd-mon-yyyy');
l_person_id number := 31524;
l_life_event_id number := 41775;
BEGIN
dbms_output.ENABLE(1000000);
per_checklist_events.create_event
(p_effective_date => l_target_start_date
,p_person_id => l_person_id
,p_assignment_id => null

9. ,p_ler_id => l_life_event_id);
EXCEPTION
WHEN OTHERS THEN
v_error := SUBSTR(SQLERRM,1,250);
dbms_output.put_line(v_error);
END;
commit:
This has the effect of creating the Pending row on PER_BEN_IDENTIFIED_EVENTS. Once
that is present it will be picked up by the Allocate Checklists and Tasks concurrent program.
This concurrent program can also be called directly. For example
DECLARE
l_errbuf varchar2(2000);
l_retcode varchar2(1000);
BEGIN
per_checklist_events.allocate_tasks
(errbuf => l_errbuf,
retcode => l_retcode,
p_purge => 'Y');
END;
commit;
If a Checklist had not been previously allocated, the allocate_tasks process should be run.
Howvever if a task has been added to an existing checklist after allocation to a group of
employees, the additional task can be added either manually in the Allocated Checklists page, or
by the allocate_person_tasks procedure as described below. A Pending row must have previously
been written to the per_ben_identified_events table using the create_event procedure.
DECLARE
v_error varchar2(4000);
l_person_id number := 29622;
BEGIN
dbms_output.ENABLE(1000000);
per_checklist_events.allocate_person_tasks
(p_person_id => l_person_id);
EXCEPTION
WHEN OTHERS THEN
v_error := SUBSTR(SQLERRM,1,250);
dbms_output.put_line(v_error);
END;
Using Allocated Checklists Window in the Professional User Interface (PUI)
You can call the Allocated Checklists window from the Enter and Maintain Person form
(PERWSHRG) by adding the following function to your Navigator menu:
HRALLCKL_PER_TF - Allocated Checklist (Task Flow)
Then add the HRALLCKL_PER_TF node to you person taskflow, and then as a Navigation
Option under the NPERSON node.
Accessing Ex-Employees in the Allocated Checklists window

10. You can view Ex-Employees using the Allocated Checklists window in the PUI, and in Self
Service by setting the &pEnableTerms=Y parameter on the following functions:
HR_ALLOCATED_CHECKLIST_MGR_SS - Manager Self Service
HR_ALLOC_CHECKLIST_ADV_SRCH_SS - HR Professional 4.0
Troubleshooting
The likeliest problem to occur with Checklists would be a failure in the allocation process.
1) Check to see if the Life Event was processed for the individual by examining if a row was
created on per_ben_identified_events. Note that the rows are cleared if the purge parameter is set
to Yes when running the Allocate program, so it's a good idea not to purge initially. If there is a
row there either Pending or Processed the problem wouldn't be with the Life Event.
If a row is not created, the event defined in Person Changes on the Life Event is not happening.
Checking an individual's data using pis11i.sql Note 275483.1 or per12.sql Note 168181.1 may
help to understand why. For example, a common misunderstanding is to set up a Life Event for
Terminations, and to check for a change in Assignment Status. Most of the time the status
doesn't change when an assignment is terminated. The record is merely end-dated.
2) Another possibility for a failure with the allocation process would be that the eligibility profile
is excluding the person. Check the profile eligibility criteria matches the employee's criteria.
3) If the problem is not obvious, then a PYUPIP trace can be run to try and identify the problem.
Ensure there is a Pending row on per_ben_identified_events for processing:
Open two sessions on the server.
Session 1
in sqlplus apps/apps
SQL> select userenv('sessionid') from dual;
Session 2
cd $PAY_TOP/bin
PYUPIP apps/apps <sessionid> > file.dmp
where : apps/apps is the login and password for the APPS schema.
<sessionid> is the value returned from Session 1.
Session 1
exec hr_utility.trace_on;
DECLARE
l_errbuf varchar2(2000);

11. l_retcode varchar2(1000);
BEGIN
per_checklist_events.allocate_tasks
(errbuf => l_errbuf,
retcode => l_retcode,
p_purge => 'Y');
END;
exec hr_utility.trace_off;
You will need to ctrl/c the PYUPIP session and then analyze
the trace statements written to file.dmp
Still Have Questions?
To discuss this information further with Oracle experts and industry peers, we encourage you to
review, join or start a discussion in the E-Business Human_Capital_Management Community.
To provide feedback on this note, click on the Rate this document link.
Copyright � 2008 Oracle. All rights reserved. Oracle is a registered trademark of Oracle.
Various product and service names referenced herein may be trademarks of Oracle. All
other product and service names mentioned may be trademarks of their respective owners.
Disclaimer: This document is provided for information purposes only and the contents
hereof are subject to change without notice. Oracle does not warrant that this document is
error-free, nor does it provide any other warranties or conditions, whether expressedorally
or implied in law, including implied warranties and conditions of merchantability or fitness
for a particular purpose. Oracle specifically disclaims any liability with respect to this
document and no contractual obligations are formed either directly or indirectly by this
document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without the prior written permission of
Oracle.
REFERENCES
NOTE:375119.1 - Users Created after AME.B Do Not Have Proper Grants / Cannot Access
AME Application After Applied AME B

12. NOTE:744150.1 - Understanding and Using Checklist Items in People Management
NOTE:168181.1 - Diagnosing Oracle HCM Person Issues Using PER.zip