[{TableOfContents }]
\\
The Approval Process definitions identify which transactions require approvals, the authorized approvers and the levels of approval required.  The Approval Process begins as soon as an employee (or other person) "submits" a transaction.

Approvals may be done in eP or Self Service, by managers and/or administrators.  Supervisors who log into the Manager Self-Service module can view and approve transactions initiated by their employees.  Administrators who log into eP or HR Self Service can view and approve transactions initiated by the employees they are authorized for.

!!What can be approved?
||Applicant Hires|  Approval of new hires is done on [IRAP], [IRCA] and [IRPO].
||Assessments|  Approval of assessments is done on [IRSA].
||Benefit Elections|  Approval of benefits selected on the eP or Self Service election forms is done on [IBEL] or WxDAR.
||Class Registrations|  Approval of class registrations for employees is done on [ICRSE] or WxCAT.
||Classes|  Approval of training classes is done on [ICRSC].
||Courses| Approval of training courses is done on [ICRS].
||Development Activities| Approval of activities created for development programs is done on [ICDA] or [ICDP].
||Development Programs| Approval of development programs is done on [ICDP].
||Job Requisitions|  Approval of job requisitions is done on [IRPO] and [IRPOA].
||Leave Lines|  Approval of leave requests is done on [IAAL].
||Pay Header Batches| Not currently available
||Pay Transaction Batches|  Approval of payroll transaction batches is done in [IPTR] or [IPTRB].
||Performance Reviews| Approval of performance reviews is done on [ISRV] and [ICPD].
||Personnel Actions| Approval of personnel actions is done on WxDAR and [ISPA] through the [MSSPA] dialog.
||Time Sheets| Approval of time sheets is done on WxDATS, WxPTS, WxTTC, WxTTS and [IPTS] through the [MPAPTS] dialog.
||Training Resources| Approval of training resources is done on [ICRS] and [ICRSC].


!!How to Define an Approval Process

Processes are defined in [IDAP] with an [Approval Process|APPROVAL_PROCESS_CODE], a type of approval being defined using the [Type|APPROVAL_TYPE] and a description.

Approval Processes can be refined using a Where Clause.  The Where Clause acts as a filter to qualify the transactions that are to be handled by the process.  For example, if there is a special set of approval rules for wage changes, a Personnel Action type approval process can be set up with a where clause that restricts the process to PA’s that have a change reason of “A WAGE INCREASE”.  All other types of PA’s would not qualify.

A priority may be specified to indicate the order that the approval processes are checked.  The priority will be used when the approval service is deciding which process applies to the approval entity.  Processes are grouped by type and ordered from highest to lowest.  Caution should be used since if left empty the ID value will be substituted.  This may cause unexpected results if one of many is left empty.  The suggested set up is to define a priority when multiple of the same type exist.

Approval Processes can also be defined using a start date and/or an end date where the rules are considered to be “effective”.  If the current processing as of date falls within the time frame specified the approval is considered effective.

!What are Priorities? 
When you have more than one Approval Process for any given Approval Type that are differentiated by using where clauses, in order to ensure that they are processed properly, they must be given a processing priority.

To get the best performance, processing should begin with the most specific (smallest) group of employees and finish with the least specific (largest) group.  High priority numbers are processed first.  Therefore, you want to process the most specific (smallest) Approval Process first and end with a general Approval Process that will process all remaining employees.
This accomplishes two objectives.  Employees are processed in the proper order and eliminated from further processing which is more efficient. More importantly, it also prevents employees who are both part of a general group (entity) as well as a specific group (department) from getting processed and eliminated from further processing as part of general group before they get processed in their proper specific group. 

Example: You have a situation where Department A has a different benefit election approval process than the rest of the company. If you set the priority for Department A’s approval process to be processed after the approval process for the rest of the company, then all employees in Department A will be processed as part of the whole company and will never be processed as Department A. However, if you set the priority to process Department A first, they will be processed correctly, eliminated from further processing, and then the rest of the company will be processed as required.

No employee in the organization will ever be processed twice for the same Approval Type.  Once someone has qualified they are excluded from further processing.
 
!Setting up by Approval Type with Sub Types
Within the Approval Type of Personnel Actions there are many PA Types and within each PA Type there can be many Approval Processes.
Each Approval Process within each PA Type will need to follow a specific processing Priority, so can break them down into Series.  

For example:
\\4000 Series:	WEBEL	Benefit Election Requests
\\3000 Series:	WEEPP	Personal Profile Change Requests
\\2000 Series:	WMEPR	Promotion Requests
\\1000 Series:	WMETR	Termination Requests


Within each series, set the processing Priority for the different sub-types, starting with the most specific, and ending with the least specific.

[Example of Approval Type with Sub Types|EXAMPLE APPROVAL WITH SUBTYPES]

!Approval Steps
For each Process multiple [steps|APPROVAL STEPS] or at a minimum of one step must be defined, sequenced and given a description.  For each step [approvers|APPROVERS] and approval records maybe maintained and viewed. 
 

!Approvers
[Approvers|APPROVERS] are defined by selecting an Approver Type.  Supported Approver types as defined in [X_APPROVER_TYPE] lexicon. 


[Approvers|APPROVERS] may be restricted using a “WHERE_CLAUSE” ([IMDAO]) to which approval entity they can approve within this process.    

Example: For the PA being approved above the PROCESS has already said that only PA’s of type  “A WAGE INCREASE” will be approved.  And the specified [approver|APPROVERS] can now only approve PA’s for employees in a specific “DEPARTMENT”.

[Approvers|APPROVERS] that qualify in the where clause are then assessed for their particular type.  (Department Manager, Position Manager, Assignment Manager, Any Manager, Specified Person, Spec List Of People) 

The “Manager” types are considered to be off the prime assignment for the identity of the approval entity. Ex: For the PA in the example above.  This PA is for a specific person.  The manager defined on the prime assignment either for department, position, 
assignment or any person who is a manager at any of the previous levels will qualify as an approver for the above approval step.

The “Specified Person” is the selected identity as the qualified approver the above approval step.

The “List of People” allows all identities in the list as qualified approvers.  

Note: People lists that are generated through eP can only be used in this selection. These people lists use the “WHERE CLAUSE” functionality as defined in [IMDAO].
 

Alternate approvers may be defined for individual approvers so that transactions may be approved whilst the original approver is away. For more information on alternate approvers please read [Designated Approvers|DESIGNATED APPROVERS].
!Approval Records
Approval Records contain such information as the Approval timestamp, the Status of the approval and the reference ID the approval is for.

When an approval Entity becomes eligible for approval,  “Notification approval records” are created.  These are approval records with the approval status of “Ready for Approval”.  There is one record for each identity defined as an [approver|APPROVERS] for the first step of approval.  These records in conjunction with work flow can be used to notify [approvers|APPROVERS] of pending approvals.

Once an approval is made (for example a time sheet) an approval record is created for that identity with the appropriate status (approved, not approved, cancelled).  At this time the old “notification records” are removed and notification records are created for the next step.

The next step will be determined by a couple of factors.  1. the current step and its next defined step. 2. the step that the approver identity is part of and if that identity is an up to approver. 3. If there are any more steps in the process.
 
;Approval Work Flow Notification

Approval Records are used in several ways to compliment the approval system.  One of the usages is Work Flow.  Work flow is provided on the table [P2K_CM_APPROVAL_RECORDS].    This enhances approvals by adding all standard features of work flow such as emails, user calcs and in turn procedures.

The term “Notification records” has been used to describe the records created to “notify” an [approver|APPROVERS], say for example an assignment manager of a pending approval via email using work flow.   If on step one an [approver|APPROVERS] is required to make an approval.  Once the approval entities stage is set to Stage_waiting_approval  an approval record or notification record is created.  This record has a status of “Ready to be Approved” as defined in the lexicon [X_APPROVAL_STATUS].  Up to Approvers also get a notification record with the status of “Approval In Progress”

;Approval Deletion or Cancellation
Since approval records are used in a few ways to notify [approver|APPROVALS] of pending approvals like screens (SS) and work flow, approval records are maintained in cases where the approval entity is deleted or cancelled.     The approval record status is updated to cancelled and will have a comment made if deleted.


[{If var='loginstatus' contains 'authenticated'

----
![Discussion|Edit:Internal.APPROVAL+PROCESS] 	
[{InsertPage page='Internal.APPROVAL+PROCESS' default='Click to create a new discussion page'}] 	

}]