Approvals may be done in Wiki 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 Wiki or HR Self Service can view and approve transactions initiated by the employees they are authorized for.
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 Wiki 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. |
Class Schedules | Approval of class schedules is done on ICRSC. |
Classes | Approval of training classes is done on ICRSC. |
Clock Entries (Authorize) | Approval of clock entries may be done on ITAPC or WATAPC or WVTAPC. |
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. |
Open Enrollment EEs | Approval of Employee Open Enrollments is done in IBPOE. |
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. |
Positions | Approval of positions is done in an extended version of IDPS. |
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. |
Processes are defined in IDAP with an Approval Process, a type of approval being defined using the 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. For more information on using where clauses in an approval process please read the page Using Where Clauses in Approvals.
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 (or after the start if the end date is not provided or before the end date if the start date is not provided) the approval is considered effective.
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:
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.
Each approval process within each PA type will need to follow a specific processing priority, so they can be broken down into individual 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
Approvers are defined by making a selection from the Approver typelexicon.
Approvers may designate a temporary replacement in two capacities. Either a “Replacement” or an “Alternate” may be defined. Replacement designates relieve an approver of all approval responsibilities starting as of the “From date” and end on the “To date” starting at 12am on the date specified. If these dates are left blank (null) the beginning of time and end of time are assumed respectively. When an alternate is defined all responsibilities are shared by the specified person and the original approver. Both types of replacements may be specific to a certain type of approval.
Ex: a Manager may be away for a vacation and time sheets may need to be reviewed during that time frame so an alternate or replacement may be assigned specifically to “Time Sheets”. If there was a salary review during that time, it would remain the responsibility of the original manager to approve. When responsibility is transferred from the approver to the designate for a replacement, all approval records previously created for notification are moved from the approver to the designate when the new designate record is saved. This will cause work flow, all approver screens and self service splash “to do” lists to now be full for the existing approvals previously required for the approver. Any new approvals required will create new approval records for the designate and the original approver will not be notified.
Alternate designates will have a copy of the approval records created for them and the original approver will retain all existing approval records. Both the alternate and approver will receive notification of new pending approvals.
The maintenance of the approval records as described above will be limited to the specified approval types. If none are listed all approval records will be subject to this maintenance.
A where clause may be defined in IMWC or IMDAO. Once a where clause is defined it may be used to control what gets approved and by whom when using it at two levels. The first is by the approval process itself and the second is by each approver. In both cases the where clause must be relative to the approval entity as the base table.
Example: Personnel Action where clause: This condition is attempting to restrict to a position code. In order to do that the condition must start from a column on p2k_sa_personnel_actions. This example works its way from p2k_sa_personnel_actions then to the prime assignment on p2k_hr_assignments ,then to the effective details of that assignment (p2k_hr_assignment_details), then to the position (p2k_cm_positions) on that assignment as noted from the foreign keys in the condition column. The “value” is the restricted position code.
Approval Bar The approval bar is divided into sections which represent each step in the process. The description of each step is displayed in bold to identify the step. Below the description is 1 approval record status used to describe that status of that step. In the example above an approval has been made on step 1 by the department manager and step 2 is ready to be approved by the HR personnel approver. To help show the status of each step is 2 chevrons colored green and red. Green notes an approval has been made and red notes a step waiting approval.
Each step has two methods of making an approval. The first is the quick approve, noted as a check mark on the step which the approver (user) has rights to approve. If the user is not an approver with rights to approve the quick approve is not available. When the quick approve is clicked an approval is made and the process is progressed to the next step or final approval as required. An option to make comments is not available.
The second is a menu available with a right mouse click over the waiting step. The first menu item is a text item showing the approver name. The three options following that are approve, decline and send back with comments. The approve action on the menu provides an option to add comment to the approval via a dialog. The dialog has an optional comment box and approve or cancel action buttons. The approve will advance the process to the next step or make the final approval as required.
The approval bar menu also provides the same type of dialog for Decline with comments and Send back with comments. The last part of the approval bar is the information icon located to the immediate right of the approval bar. When clicked this action displays a view only dialog showing a record representation of the existing state of the approval proceeds based on the current approval records. Details shown include Date and time of the approval record creation, Step sequence, Status of the approval record, Approver Type, The identity for which the approval record was created, and optional comments made by an approver. These details may be viewed with more detail by day in DDAPR (see the Approval Screens section below) This dialog is based on the form (function)MDAPR.
Approval Action Button The second type of interface is simply an action button located on various forms. The approval screens list below includes the type of action GUI provided.
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 for the first step of approval. These records in conjunction with work flow can be used to notify approvers of pending approvals.
Each stage dictates what approval records are created. The Approval records are what is used to create a visual (approval bar) or report ( discoverer) to show where and who the approval sits, whether it`s before during or after the approval.
The current supported approval record statuses are:
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.
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, say for example an assignment manager of a pending approval via email using work flow. If on step one an approver 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”
Cancelled Example: Deleted Example: Status is cancelled with a comment showing the entity was deleted.
When a step is ignored it will not show in the approval bar or have approval notification records created. It will appear as if the approval process did not have that step defined. When the empty step is the last step in the process the last approval made will be considered final approval and the approval entity will be updated to the “approved” stage.
Example: Approval Process – Where clause = PEAS Personnel Actions only.
Up to Approval When Up to Approval is checked that approver is eligible to approve entities which they qualify for via the where clause, including entities that are waiting approval on a step with a lower sequence. When up to approval is granted “notification records (approval records)” will be created with a status of “Approval In Progress” (Notification records are discussed further in Approval Notification /Workflow). Allow Send Back This setting applies to a second level of approval or higher. If at the time of approval the approver does not like what they see the option to send the entity back to the beginning of the approval process is available. This will set all previous step approvals (approval records) to have a status of “Approval Sent Back” which will cause the first step approvers to be notified (via new approval records) to once again approve the entity. Comments as to why the send back was made may be entered if necessary. This option is available in eP as an option in the right mouse click menu over the appropriate step on the approval bar. Allow Decline This setting allows the approver to decline the approval entity. The option is applicable to all steps the approver is responsible for. If a decline is made the approval process is complete, no further approval notification is necessary. This option is available in the right mouse click menu. Comments as to why the decline was made may be entered if necessary. Allow Change This setting will cause the approval entity to be editable or not during the approval. In cases where the approver is allowed to view only while making the approval.
Change is allowed. Notice the updateable details of the PA: Change is NOT allowed. Notice the non-updateable details of the PA: Once an approval entity has entered the approval stage (explained below) of "Stage_WaitingApproval" CRUD will be controlled to the appropriate approver. This means that only approvers who have rights to approve on the current step with "allow change" rights will be able to edit the information displayed.
Personnel Actions – PA Status mappings translating from pa_status to approval stage.
Pending | Stage_WorkInProcess |
In Progress | Stage_WaitingApproval |
Submitted | Stage_WaitingApproval |
Failed Update | Stage_Approved |
Approved | Stage_Approved |
Completed | Stage_Approved |
Not Approved | Stage_Not_Approved |
Tracked Copy | Stage_Cancelled |
Cancelled | Stage_Cancelled |
Personnel Actions – PA Status mappings translating from approval stage to pa_status
Stage_WorkInProcess | Pending |
Stage_Not_Approved | Not Approved |
Stage_Cancelled | Cancelled |
Stage_WaitingApproval | In Progress |
Stage_Approved | Approved |
If an approval entity is moved to the approval stage “Stage_WaitingApproval” and there has not been an approval process defined a generic 1 step approval bar will be displayed. Any user with access to the function and data may approve this type of approval. No approval records are ever created. The status of the approval entity is simply updated to the next stage upon approval.
A generic approval would be displayed as below with the right mouse click menu:
This section has been replaced with the site preference described below available in 4.09
Two self service screens listed below have a toggle available for use located in the find block of each function. This toggle enables the data listed in the find block to change dynamically to show “potential” approvals verses “actual” approvals.
WVDATS | Approve Time |
WVTSH | Approve Employee Time and Exceptions |
It is highly recommended that properly built where clauses are used on both the approval process and approver levels. If the refining of approval processes and approvers is not properly done performance will be an issue. Consultants would be a good source to help ensure that all filtering is done properly to avoid any performance problems. Below is an example of too many rows for an approver to manage.
The site preference APPROVAL_WIP_REC now replaces the old simulation logic applied when trying to find the possible approvals an approver may need to make. This logic gives more of an accurate view of the up and coming approvals by monitoring specific tables defined by this preference. In IMST, preference records may be added as in the above example for table TIME
Screen captures are meant to be indicative of the concept being presented and may not reflect the current screen design.
If you have any comments or questions please email the Wiki Editor
All content © High Line Corporation