(AWE) Approval Workforce Engine Design Presentation to UCSB BPM Team March 13, 2013 Presented by Catherine Luinstra-Uster UCSB HR SME

Types of People Person of Interest/POI –Has a relationship with the University but is not an employee and is not paid Associate of the President/Chancellor External Compliance/Auditor Potential Hire UC/OP/Affiliated Organization Unknown Contingent Worker –Has an organization relationship with a department but is not an employee and is not paid –Contingent Worker Job Code CWR - UCB Student Facilitator CWR - LBL/DOE Post Doc CWR - Visiting Student Researcher CWR - Staff Intern CWR - Affiliated Research Institute CWR - Independent Contractor/Consultant CWR - Clinical Associate/Admitting Physician CWR - Non Research Fellow CWR - Temp Agency Staff-Health CWR - Temp Agency Staff-Non Health CWR - Volunteer CWR - Traveling Nurse CWR - Community College Instructor Employee –Has an employment relationship with the University Update employee data –Status, Termination –Pay, Stipend 2

Employee Classes in PeopleSoft Academic Academic - Faculty Professor SOE NSF Lecture Visiting Adjunct Professor Academic - Non Faculty Researcher Project Scientist Specialist Postdoc Academic Coordinator Visiting Academic - Student Graduate Student Researcher TA Associate Reader Rem Tutor Academic - Recall All Titles Contingent Worker - Academic WOS Research Visitors Staff Contract Career Limited Per Diem Partial Year Career Floater Rehired Retiree Contingent Worker - Staff 3

Custom Forms for Entering Data with Approval Workflow Engine (AWE) Custom Forms: Template Based Hire (Rehire) Additional Pay –Stipend –Specialty & Certification Pay –Summer Salary –BYA Data Change –Probation End Date Transfer –Transfer to another position/job Earning Distribution Change Short Work Break –Students employees on break for the summer Pay Rate Change –Equity Increase Retirement Termination –Voluntary –Involuntary –Layoff –Death Draft Termination Form 4 Design of the Approval Workflow Engine (AWE) Campuses provided feedback The design was changed based on campus feedback New design will provide more flexibility for the campuses Each UC Business Unit (Campus/Medical Center) will be able to select which route and final approver they wish to use for each custom form/transaction type (vary by Business Unit)

Entering HR/AP Transactions Campuses will not be entering data directly into PeopleSoft Custom front-end forms and AWE solution has been developed to accommodate UC requirements and to update data in PeopleSoft, and address routing and approval issues Approval Workflow Engine (AWE), will allow locations to route HR/AP transactions for approval prior to submission to the UCPath Center AWE will allow routing by each Employee Class in PeopleSoft HR Approver 1, Approver 2, Approver 3 AP Approver 1, Approver 2, Approver 3 Student Approver 1, Approver 2, Approver 3 HR/AP Approver 1, Approver 2. Approver 3 Career Student Faculty CWR 5 Initiator Employee Class

Set up Considerations The route and final approver for each custom form cannot vary within a single Business Unit (Campus/Medical Center) Approvers do not need to be in the same department to be designated as a department Approver An Employee must have been given the security role (e.g. Approver 1) in PS before they can be added to the routing table Approvers are able to initiate transactions as well as approve An approver is required within the routing table at the last step –AWE functionality will skip blank non-final levels –AWE will give an error if no approvers are found at the final approver level for the transaction Comments will be required for any transactions that are pushed back or denied 6

Campus Approval Level/Final Stop Set Up for Custom Forms UCSB will need to determine the final stop/approver for each type of transaction Once the final stop/approver approves the transaction the transaction is routed to the UCPath Center for input into PeopleSoft Pay Rate Change Approver 3 Transfer Approver 2 Data Change Approver 1 Final Stop Example 7

Roles within AWE Levels of defined approval workflow roles include: –Initiator –Approver 1 –Approver 2 –Approver 3 –SMG Approver –Location Administrator (not an approval role) Each approval level can have multiple approvers designated to that level for a specific department Allow for defined, as well as ad-hoc Reviewers and Approvers Each Campus (Business Unit) will work with their departments to establish and maintain a table that defines the specific Approver(s) for each Employee Class (e.g. Career, Limited, Academic-Faculty) 8

Capabilities of Approvers Once roles have been designated, Initiators and Approvers will be able to: –Execute all Workflow Approval actions –Initiate and/or Approve actions for employees in the designated department/Employee Class Edit transactions per the agreed upon fields –The forms will not reflect what specifically was edited or by whom, although those items will be tracked in an audit table –Not all fields will be editable As determined by the Practice Board, any key fields (i.e. employee id, record number and action) and fields related to dollar amounts will not be editable Approve/route to the next level approver, ad-hoc reviewer or ad-hoc approver Push back to the Initiator –Comments are required Deny the transaction –Comments are required 9

Set Up for Each Department and Approvers 10

Notification Setup During the process of a transaction, a number of notifications will be sent to the users involved in the transaction: When the transaction is submitted, an notification will be sent to all approvers selected in the table at the first level for that employee class. An will be sent to all approvers selected who have the " ?" flag on the Department Approver setup page turned on. When the transaction is approved at a non-final level, an notification will be sent to all approvers selected at the next level. If the transaction has reached the UC Path level, no approvers will receive an . When the transaction receives final approval, an notification will be sent to the initiator. (This is the point at which the data is entered into the delivered PS tables via a CI) When the transaction is denied, an notification will be sent to the initiator and any approvers who approved the transaction prior to its ultimate denial (a comment is required). When the transaction is pushed back, an notification will be sent to the approver selected at the level to which the transaction has been pushed back. When a transaction has been waiting at any level for more than 3 days, an notification will be sent to the initiator, the current approvers, and the Administrator list. 11

Termination All Terminations transactions will be routed and approved the same way regardless of the reason Voluntary Resignations Involuntary Terminations Layoffs Medical Separation Death 12

Termination Example by Employee Class Termination transactions can be routed based on Employee Class but can not be routed based on the termination reason Voluntary Resignations Involuntary Layoffs Medical Separation Death Academic Example Dept. A, B, C, D, E, F Initiator - Multiple support staff Approver 1 - Business Officer Approver 2 - Level left blank Approver 3 - Academic Personnel Dept. Employees Staff Example Dept. A, B, C Initiator - Multiple support staff Approver 1 - Business Officer Approver 2 - Control Point Approver 3 - Human Resources Dept. Employees Student Example Dept. All Depts. Initiator - Multiple support staff Approver 1 - Level left blank Approver 2 - Level left blank Approver 3 - Student Dept. Employees Example: Approver 3 is the final approver/stop for all Employee Classes Approver 2 is blank for Academic example Approver 1 and 2 are blank for Student example 13

Template Based Hire (TBH) Validation of no prior UC affiliation Type of Rehire Retiree Layoff Recall Reinstatement 14

Pay Rate Change Centralized process for mass updates such as step increase/progression, merit Coordination of reclassification title changes performed on the position 15

Additional Pay Additional compensation is any cash compensation above a University employee’s regular, base compensation. Recurring payments that are paid over multiple, consecutive, pay periods (i.e. Stipend for 6 months) or as specified by the earn code (i.e. Summer Salary). –Examples: Academic Summer Salary Stipends Perquisites Automobile Allowances Housing Allowances Certification Pay Differentials “Z” payments Compensation for certain jobs, when such compensation is non-regular, i.e. not UCRP covered compensation. These recurring payments are set up in the Additional Pay page rather than as Compensation in the job record. –Examples: UNEX CME Summer Session Instructor Pay Academic Administrative Stipends BYA Faculty Recall Pay Recurring vs. One Time Payment Pay Periods (First, Second, Third) Earnings Code/Reason Code 16

Data Change Updates that cross Multiple areas of responsibility Academic - Reappointment Benefits - Eligibility, Retirement Plan Payroll - FICA Status, Tax Location Employment - Extension, Limited to Career Employee Relations - Probation Code 17

Transfer Transactions that cross multiple areas of responsibility Employment – Promotions Employee Relations - Demotions 18

Short Work Break New process and Training Furlough Students 19

Earnings Distribution New process and training 20

Retirement Accurate Dates Separation vs. Retirement Date 21

Considerations/Decisions to be Made Final Approver Level for each type of transaction –Approver 1 –Approver 2 –Approver 3 Maintenance of Approvers in the System –Approval Process –Adding, Updating and Changing Approvers Workflow for each Employee Class –Identifying processes and approvers (same/different) Training –New Process and System (e.g. Entering Stipends) –New Action and Reason Codes –Data Quality, Auditing –Effective Dates (History, Current and Future rows of data) –UCPath Center Support (Corrections and Retroactive transactions) HR Transactions Impact on Other Modules –Payroll –Benefits Campus Business Processes vs. UCPath Business Process Maps 22