12
Page 1 of 12 UH PeopleSoft 9.2 Workflow Roles - Cheat Sheet Description Review how workflow is applied to Job Data and Position Management Transactions In PS 9.1 submission and approvals for Job Data and Position Data requests occurs outside the system, by obtaining signatures on paper documents (PNF for Job Data transactions, SF-1, SF-2, HRD-1 and Form 13 for Position Management requests). In PS 9.2, all PS related requests are submitted through PS and reviewed and approved in the system. This does not include the following requests, which must be made outside the system: 1) Position Requests for generic positions (GA, Casual, Overload, and Lecturer) 2) Prior Authorization for Job Data transactions (account code changes, extension of apt period) if approval is required by person outside the Job Data workflow. When a transaction is Submitted for review and approval in UH Job Data and UH Position Management, it will trigger a workflow that will route the request appropriately. Example of Job Data Workflow: Example of Position Management Workflow:

UH PeopleSoft 9.2 Workflow Roles - Cheat Sheet

Embed Size (px)

Citation preview

Page 1 of 12

UH PeopleSoft 9.2 Workflow Roles - Cheat Sheet

Description Review how workflow is applied to Job Data and Position Management Transactions

In PS 9.1 submission and approvals for Job Data and Position Data requests occurs outside the system, by obtaining signatures on paper documents (PNF for Job Data transactions, SF-1, SF-2, HRD-1 and Form 13 for Position Management requests). In PS 9.2, all PS related requests are submitted through PS and reviewed and approved in the system. This does not include the following requests, which must be made outside the system:

1) Position Requests for generic positions (GA, Casual, Overload, and Lecturer) 2) Prior Authorization for Job Data transactions (account code changes, extension of apt period) if approval is

required by person outside the Job Data workflow.

When a transaction is Submitted for review and approval in UH Job Data and UH Position Management, it will trigger a workflow that will route the request appropriately. Example of Job Data Workflow:

Example of Position Management Workflow:

Page 2 of 12

Job Data transactions for BOR employees in PS 9.2 have a relatively brief workflow, with only 2 levels of review: 1. The designated (through KFS) Fiscal Administrator(s) for the account code(s) funding the employee; 2. The Appointing Officer, as designated by unit.

See below** for an explanation of Civil Service Job Data workflow. The reason for this expedited review is that the PNF can only be generated when the transaction is reviewed and approved by both the Fiscal Administrator and the Appointing Officer. This is important for PNF’s that need to be generated prior to emergent Payroll deadlines. In some cases, there may be Multiple Approvers assigned to a role in the workflow. Users can identify the approvers by clicking into the box, which pops out an approver list. Contact information is also included in this pop-up box, and the box will appear with the contact information even if there is only one approver.

Page 3 of 12

After the Job Data request has been submitted by the HR Specialist, the Fiscal Administrator will receive an email that a request is awaiting their action, with a link to the PS 9.2 system tied to the transaction. Inside PS 9.2, the FA will also receive a Flag notification at the top corner of their screen (located near the NavBar) that a request requires their attention.

Clicking into the Flag will show the current transaction that requires attention (unchecked actions will have a blue dot to the side).

Page 4 of 12

Clicking into the transaction from the Flag list will take the FA to the Job Data request. The FA can view all requested changes to the Job Data record. If the Fiscal Administrator does not agree with the changes, they can Pushback the request, using the Justification/Comment box to detail the required changes. When an request is push back the Initiator will have the opportunity to make changes to the request and resubmit.

Likewise, they can Deny the Job Data request, but doing so will remove the Job Data request altogether. Deny should only be used if the FA is sure the request should NOT be approved.

Page 5 of 12

When the FA is supportive of the Job Data transaction, they will click the Approve button. This will update the transactions status to Approved by FA (in green), and route the request to the Appointing Officer. NOTE – If there is more than one account associated with a Job Data request, ALL responsible FA’s must review and approve the changes. It will not be routed to the Appointing Officer until all it receives all approvals by the listed FA’s. NOTE 2 – Workflow for PS 9.2 is set up such that Initiators cannot approve the requests that they’ve generated. In this case, Brenda Shin, the Initiator, is also listed as the Appointing Officer. Her approval will be skipped and another assigned Appointing Officer must approve the transaction.

Page 6 of 12

FA’s, as well as Appointing Officers, can also view transactions for their approval through the Worklist.

Like the FA, when the Job Data request is routed to the Appointing Officer, they will receive a notification email with a link to the transaction in the system. Additionally, in their PS page, they will receive the Flag notification and with the list of pending transactions.

Page 7 of 12

Again, the Appointing Officer can Pushback (to the FA), Deny, or Approve. When Approved, the Job Data request status will be updated, the updated row will be added to the employee’s Job Data profile, and a PNF will be generated. The Appointing Officer should receive the messages below:

Page 8 of 12

When a request is approved, the Initiator will receive notification via email that the request is approved. In the system, they will receive Flag notification that the request is approved.

Clicking into the transaction will allowed them to view the approved transaction, which is now a Job Data row on the employee’s personnel profile. At this point the Initiator should also verify the details of the PNF.

Page 9 of 12

The PNF will show the Initiator and the Approver’s of the transaction, with a time/date stamp.

Some Job Data actions do not require Workflow approval, and can be Self-Approved by the user and added to the employee’s Job Data. These include the following actions:

Data Change DTA 909 WARRANT DISTRIBUTION CHANGE Data Change DTA 930 CHANGE APPROVER Data Change DTA 931 CHANGE REPORTS TO/SUPERVISOR Data Change DTA 940 PROBATION OR TENURE STATUS Data Change DTA 905 CHANGE IN RECORD – PAYROLL Data Change - Correction DTC 909 WARRANT DISTRIBUTION CHANGE Data Change - Correction DTC 930 CHANGE APPROVER Data Change - Correction DTC 931 CHANGE REPORTS TO/SUPERVISOR Data Change - Correction DTC 940 PROBATION OR TENURE STATUS Data Change - Correction DTC 905 CHANGE IN RECORD – PAYROLL NOTE: Although each of these actions independently may be Self-Approved by the Initiator, if in combination with any other actions as part of the transaction, they will be subject to review and Workflow approval.

Page 10 of 12

Additionally, not all Job Data actions will result in the generation of a PNF. These include the following actions:

Data Change DTA 293 JOB INDICATOR CHANGE Data Change DTA 470 EXTENSION OF APPROVER Data Change DTA 930 CHANGE APPROVER Data Change DTA 931 CHANGE REPORTS TO/ SUPERVISOR Data Change DTA 940 PROBATION OR TENURE STATUS Job Reclassification JRC 980 CHANGE FROM OVERLOAD TO CASUAL Data Change - Correction DTC 293 JOB INDICATOR CHANGE Data Change - Correction DTC 470 EXTENSION OF APPROVER Data Change - Correction DTC 930 CHANGE APPROVER Data Change - Correction DTC 931 CHANGE REPORTS TO/SUPERVISOR Data Change - Correction DTC 940 PROBATION OR TENURE STATUS Data Change - Correction DTC 905 CHANGE IN RECORD – PAYROLL NOTE: Although each of these actions independently may not generate a PNF, if in combination with any other actions as part of the transaction, they may generate a PNF.

**Civil Service transactions are Self-Approved by the Initiator and will generate a PNF (except as referenced above) when Submitted. They are not subject to the same Workflow as BOR positions.

Page 11 of 12

The format and functionality of Workflow in Position Management is similar to Job Data. However, Position Management requests require a more comprehensive review and validation, and introduce such roles as Requestor (who initiates the position request), Account Supervisor for BOR positions (often the Principal Investigator), Human Resources (in addition to the FA role) and depending on the type of position request and the unit, Budget Director/Officer, Dean, VC, Provost, Chancellor, VP, and President. Definitions of these workflows and the roles can be found in Workflow Charts by Employee Type and Unit. The example below shows the workflow for a Civil Service Position Management request, which is based on the HRD-1 form.

The next Approver on the workflow will receive an email, and in the system, a Flag notification (they will also be able to access a Worklist for all requests, as described above).

Any Approver in the Workflow can Pushback, Deny, or Approve, as well as enter comments that will be reviewed by successive Approvers (they can also Save the action). Deny should only be used if it is certain no action on the position will be taken.

Page 12 of 12

When Approved, the Approver’s box will be highlighted in green and routed to the next Approver until it is finally Approved and ready to be Filled.

When the position is finally Approved, the Requestor will receive an email and Flag notification stating that the position has been Approved.

To identify the status of the position request at a later time, click View Requests for New Positions on the UH Position Management Home screen.

Step 3.0 A New Position Requests section will pop out – click on the Transaction Number to view the request.