Solution Design Scope Summary

Updated on Aug 01, 2025

Revision History

Revision Control

Revision Date	Revised By	Summary of Revisions	Section(s) Revised
2/19/2020	CMS	Document created	All
3/3/2020	SWHR	Revised for publishing – Wave 1 (included	All
3/3/2020	CMS	Added Appendix B	Appendix B
4/27/2020	CHRS	Updated Appendix B	Appendix B
8/12/2021	CHRS	Updated Appendix B	Appendix B
5/6/2022	CHRS	Updated Appendix B	Appendix B
10/7/2022	CHRS	Updated Appendix B	Appendix B
1/31/2023	CHRS	Updated Appendix B	Appendix B

Review / Approval History

Review Date	Reviewed By	Action (Reviewed, Recommended or Approved)
10/23/17	CMS	Reviewed and Recommended for Approval
10/27/17	SWHR	Reviewed

Table of Contents

Revision History

CHRS Design Approach

CHRS Releases

CHRS Release 1

Future CHRS Releases.

Policies in support of CHRS

Modules included in CHRS

Out of Scope for this Design Effort

CHRS Common System Functionality FLUID

Approval Workflow (AW) Uploading Documents (Manage Attachments)

Conversion / Data Retention

Security

CHRS Business Process / User Guide

1.1 Workforce Administration

1.2 Key Assumptions

1.3 New Functionality .

1.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes

1.5 Modifications

1.4.1 Retired Baseline Modifications

1.4.2 9.2 Modification Requests

2.1 Temporary Academic Employment

2.2 Key Assumptions

2.3 New Functionality

2.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes

2.5 Modifications

2.4.1 Retired Baseline Modifications

2.4.2 9.2 Modification Requests

3.1 Benefits Administration

3.2 Key Assumptions

3.3 New Functionality

3.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes

3.5 Modifications

3.4.1 Retired Baseline Modifications

3.4.2 9.2 Modification Requests

4.1 Time & Labor

4.2 Key Assumptions

4.3 New Functionality

4.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes

4.5 Modifications

4.4.1 Retired Baseline Modifications

4.4.2 9.2 Modification Requests

5.1 Absence Management

5.2 Key Assumptions

5.3 New Functionality

5.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes .

5.5 Modifications

5.4.1 Retired Baseline Modifications

5.4.2 9.2 Modification Requests

6.1 LCD

6.2 Key Assumptions

6.3 New Functionality

6.4 Business Process Flows and Major Process Changes

Business Process Flows

Major Process Changes

6.5 Modifications

6.5.1 Retired Baseline Modifications

7.1 Recruiting

7.2 Guiding Principles Used for the solution selection:

7.3 Key Assumptions

7.4 Scope

8.0 Appendix A: Gap Resolution Requests

8.1 Legend – Software Modification Types

8.2 Workforce Administration

8.3 Temporary Faculty 1

8.3 Benefits Administration

8.4 Time & Labor and Absence Management

8.5 Time and Labor

8.6 Absence Management

8.7 LCD

8.8 Recruiting

8.9 Security

9.0 Appendix B: Change Control Requests

9.1 Workforce Administration .

9.2 Benefits Administration

9.3 Time and Labor

9.4 Absence Management

9.5 LCD .

9.6 Recruiting

9.7 Security

9.8 General

Background

This document is intended to assist in understanding the overall functionality that is included in the Common Human Resources System (CHRS). The document will be updated when appropriate as the CHRS evolves through the various development stages and Release Management.

CHRS is being built in accordance with the guiding principles defined below:

Derive CSU requirements generally from Policies & Labor Contracts
Utilize an interactive design process reviewing application functionality and CSU business process needs at the same time.
Develop common business processes utilizing the PeopleSoft HCM application as delivered to the extent possible.
Replace HCM Baseline modifications with PeopleSoft 9.2 functionality to the extent possible.
Develop modifications to the software only when necessary:
Irremovable Baseline modifications will be upgraded to PeopleSoft 9.2
If during the analysis, it becomes apparent that delivered PeopleSoft 9.2 functionality cannot support a current CSU business process, the business process will be modified wherever possible
If the business process cannot be modified, a single, uniform modification to PeopleSoft HCM application will be developed to serve all CHRS users
Campus-specific modifications will be supported only when all other options have been exhausted

The recommended process changes and modifications presented in this document are the result of the CHRS Solution Design Phases I, II and discovery in the Development phase. The Solution Design module teams believe combining these recommendations with the delivered PeopleSoft v9.2 functionality provides a design of an HCM system that best serves the needs of the CSU. This document also provides a summary for campuses to understand scope.

CHRS Design Approach

CHRS Design work occurred in two phases: The focus for Phase 1 teams was to identify gaps in the delivered HCM 9.2 product. The focus for Phase II teams was to identify standard business processes and recommend solutions for gaps, including recommendations to change CSU business/policy.

Each design team was comprised of Systemwide Business Owners (HR and Finance), Campus Leads, SCI Leads, and CMS BSAs. In addition, module status calls were held every other Thursday to share recommendations made by the design team members and demonstrations of completed modifications with campus SMEs and to collect campus feedback.

CHRS Releases

With CHRS, the CSU intends to move away from a system of disparate business processes and customized applications, to a single HR environment with cohesive business processes.

The long-term strategy of the CSU is to move to the next generation of cloud-based ERP Systems. In our current state, we are not well positioned to take advantage of these systems, nor is there a single system that can accommodate all of the needs of the CSU.

The short-term strategy is to complete a Release 1 of CHRS so we are on a common HR system, then continue to add features and functionality through future releases in a planned release environment. As we do this we are positioning the CSU to be more responsive to emerging technologies as they continue to evolve their features and functionality into a system that can accommodate the CSU in its entirety.

CHRS Release 1

CHRS Release 1 is the minimum system required for the CSU to go live with a single HR system. It will allow the CSU to deliver a system “smaller, sooner”, meaning sooner even though smaller at the start, allowing for an earlier realization of some CHRS benefits including but not limited to:

Creating a foundation for CHRS to “Build, Evolve, Grow”
Allowing campuses the ability to leverage richer features in 9.2 version
Allowing CSU to get back on Oracle support
Ensuring that the multi-campus system functions well and is suitable for use by all campuses
Allowing CSU to move forward with sustainable system

Release 1 is limited to functionality necessary to operate in a consolidated environment and isolate campus data so that the end users only access data needed to do their jobs.

The Module Solution Design teams and SWHR provided input on CHRS/PeopleSoft 9.2 configurations and submitted requests for software modification and policy changes (see Appendix A: Gap Resolution Requests (GRPs)). The Module Solution Design teams provided a recommended priority of the PeopleSoft modifications and Policy Changes. SWHR took the module teams’ recommended prioritization into consideration and made recommendations for Release 1 scope.

Since the initial Design phase was completed, Change Control was introduced. The process allows users to ask for changes. These requests go through a review process by the Module Solution Design teams and SWHR. The requests recommended are then presented to the Steering Committee for approval.

CHRS Roadmap

Items that were added to the Roadmap for inclusion in future releases met at least two or more of the following conditions:

Large amount of work effort to develop
Not currently being used at all campuses
Require additional “Meet and Confer” discussions with the Labor department and Unions*
Noted as a low priority by Module Teams

*The Labor department will begin their Meet and Confer process during the Design and Build phase of Release 1 to ensure these items are ready for future releases.

Future CHRS Releases

The CHRS Program Team is committed to the timely delivery of the CHRS roadmap and Change Control items in planned future releases. A strategy approach for future release schedule will be drafted and presented before the first Go Live. The CHRS release strategy will assume a progressive and timely delivery of roadmap and change control items to increase or restore functionality as some campuses will lose some functionality with Release 1.

The strategy will include a methodology for the selection of Software Modification(s) and Policy Change(s) (GRPs) to be included in a future release, the implementation approach and projected timelines for the phased releases as the current solution is more widely implemented.

Policies in support of CHRS

The CHRS Design Team submitted Policy Change requests which are noted in this document by module with their disposition (see Appendix A: Gap Resolution Requests (GRPs)).

In addition, SWHR (Systemwide Human Resources) may need to develop implementation policies in support of the CHRS rollout

Modules included in CHRS

In Scope for this Design Effort

Workforce Administration
Temp Faculty¹
Benefits Administration
Time & Labor
Absence Management
Recruiting built by PageUp
Labor Cost Distribution (LCD)²

In addition, the program will deliver the following:

Selective Self-Service items for Manager & Employee
3rd Party Interfaces
Delta Dental Interface
SCO Benefit Interface
PSR Interface
LCD Monthly Paytape file Load
LCD Interface to CFS
Temporary Academic Employment link to Campus Solutions
Time & Labor PIP Interface
Time & Labor link to Campus Solutions
Workforce Administration link to Campus Solutions
Workforce Administration SSI GSI Load
Implementation of Person Data Management
Centrally developed and maintained enterprise-wide HR reporting environment (CHRS Data Warehouse (DW) and PeopleSoft where the report cannot be supported by DW))

Out of Scope for Release 1

Learning Management (Enterprise Learning Management module)
Grants and Contracts* (a campus specific Bolt-On module)

Functionality for Auxiliaries and Foundation

*Note: The CHRS program team formed a workgroup to understand requirements for Grants &

Contracts, Auxiliaries and Foundation. Information will be communicated as it becomes available.

CHRS Common System Functionality FLUID

Fluid User Interface is designed to be used on mobile devices and is also used on a laptop and desktop. Greater flexibility in design is possible by cascading style sheets, scalability in viewing size for various devices, and

content presentation which will adjust to flow on multiple devices in a usable manner. An end user can interact with a conventional mouse, keyboard, stylus, or touch interface for any pages utilizing fluid depending on the device they are using.

The CHRS Program team made the recommendation to implement “Delivered” Fluid functionality in the initial phase of CHRS. This decision positions CHRS to take advantage of new Fluid functionality and minimize any negative impact from Oracle's intention to replace "Classic" PeopleSoft pages with Fluid or Classic+ pages over time and may drop support for the "Classic" pages.

Initially customizations of any Fluid pages were out of scope due to technical complexities associated with the tool set. Over the course of the Design and Build phases, small modifications have been done. It is still the recommendation to use Delivered to the fullest extent before any modification request is considered. The program team will partner with Wave 1 to address requirements to implement Fluid and prioritization of features to be delivered.

Approval Workflow (AW)

Approval Workflow provides the framework and capabilities for creating, running and managing transactions that require approvals. This includes who is included in the approvals, the order in which approvals will be completed, and how the transactions will be routed. AW will be used within Workforce Administration, Time & Labor, Absence Management and Temporary Faculty. Benefits Administration’s design does not require AW.

Uploading Documents (Manage Attachments)

Manage Attachments is functionality that is delivered by Oracle's PeopleTools allowing attachments to be uploaded and managed across all the CHRS HCM modules. Types of attachments processed by this functionality are defined within PeopleSoft and can include audio, video, binary, pdfs, word, pictures, etc. Further exploration is needed to confirm how the delivered feature can be leverage for the CSU. Currently there is a Benefits GRP on the Roadmap to address this.

Conversion / Data Retention

Conversion

Data converted from the campus 9.0 system needed to be limited. The following conversion scope was approved by the Steering Committee.

Position
- All positions - except if a campus excludes unused positions
Person
- All people, active and inactive, first row and current row (max effdt)
E99 Students
- Do not convert if only student jobs with max effdt row > 2 years from Wave 1 conversion run date
- POI pending Standardization
Job
- Active Jobs
  - First/Converted row (hire)
  - Current row (max effdt)
  - Job history (6 years from wave 1 conversion run date)
  - If rehire conversion row then also bring prior term row
  - If return from leave row then also bring prior leave row Terminated Jobs
  - First/Converted row (hire)
  - Max effdt termination row
  - Current row (max effdt)
  - Job history - none If rehire conversion row then also bring prior term row
- Student Jobs (inactive)
  - Do not convert if max effdt row > 2 years from Wave 1 conversion run date
  - E99 student jobs only
- TempFac Jobs (active and inactive)
  - First row (hire)
  - Current row (max effdt)
  - Job history (6 years from Wave 1 conversion run date)
Profile
- All Profile History
Benefits
- 2 years from Wave 1 conversion run date
Time & Labor
- 2 years from Wave 1 conversion run date; *PIP History will NOT be converted*
LCD
- 2 years from Wave 1 conversion run date
Absence Management
- Balances Only
Temporary Academic Employment
- 6 years from Wave 1 conversion run date

Data Retention

A records and retention schedule is in effect and is being revised as needed to support CHRS, where possible. The current business rules are applicable and address business rules for /purging CHRS data.

Security

Security within CHRS was addressed throughout the design and will include including but not limited to the network, operating system, database, and application levels. The core security principles for access to HR data will be based on “need-to-know” and least privileges determined by an employee’s job function. Campuses will comply with all CSU policies governing information security including the CSU’s Segregation of Duties policy. The campus security administrators will maintain user profiles in CHRS for their respective campuses including Row Level Security which will limit users to their respective campus’ data.

The Security Workgroup team has requested a number of system modifications to facilitate and adhere to the CSU standards. The modification GRPs can be found in the Security table in Appendix A.

For more information on the approach and assumptions to security roles and permission in the multi-campus environment, see the CHRS Security Strategy document.

CHRS Data Dictionary Business Process / User Guide

Several key deliverables will be available for CHRS 1) data dictionary to provide definitions of field/data element values that are valid for CHRS, 2) a guide that will provide step-by-step instructions for users within the CSU that will provide guidance to successfully establish and update employee information in CHRS. The Standardization team will be developing, deploying, and maintaining the data dictionary and the guide; 3) CHRS Business Process Guides will also be developed, deployed and maintained by the CHRS Training team.

Module Summary

1.1 Workforce Administration

The Workforce Administration (WA) pages and records are the repository for the core employee data used in all the other Modules in the PeopleSoft HCM application. The type of data stored in WA’s Personal and Job Data includes biographical data as well as an employment history for the employee’s time with the California State University (CSU). In addition, other data types such as the employee’s emergency contacts, dependents, disability identification, requests for accommodations for disability, veterans’ status, ethnicity, etc., are also stored in separate records in the Workforce Administration module.

Profile Management is a separate module that works with Workforce Administration to capture employee specific data like education, degrees, schools, licenses and certifications, etc. The Person Profiles are configurable and can be set up to track non-standard data elements. For example, Campuses are tracking outside employment for Management Personnel Plan (MPP) employees in Person Profiles.

Manage Faculty Events is considered part of the Workforce Administration realm and can be used to capture data that is unique to Faculty employees such as administrative titles, publications, committees, etc. There is also functionality to calculate Tenure for Faculty employees who are on a Tenure Track.

Position Management can be considered part of Workforce Administration. Positions work as a shortcut with Job Data defaulting data elements that comprise a Job such as “Job Code”, Department, Full-Time Equivalent (FTE), “Reports To”, etc. Positions can also be used as a budgeting tool where a department has operating dollars for a specific number of filled and vacant positions for the coming Fiscal Year.

1.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Workforce Administration solution for the CSU:

Student Personal Data can be changed in HCM and will not be synchronized back to Campus Solutions
Student Personal Data will be available in HCM through the Person Data Management (PDM)
Person of Interest (POI) type of “Unknown” will be cleaned up at the Campus and will not be converted into CHRS

1.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.

Fluid designed pages in core and in Employee Self-Service (ESS) are available in 9.2. Fluid pages use tiles rather than menu options and are designed to fit on mobile devices.

1.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in Workforce Administration Solution Design.

ID	Business Process Flow
10	Change existing position
11	Update Job W/MSS
12	Update Job Manually
14	Enter EE Additional Data
16	Track Faculty Events
17	Enter New Hire Information
19	Maintain EE Information
20	New Position Request
21	Tenure Track Process
24	Add a POI
25	I9 and Citizenship -- I9 Data
26	I9 and Citizenship -- Citizenship Information
27	Student Hire Modification
28	Manual Hire
800	Data WA Track Teleworkers
801	Data WA Accommodation Request

Major Process Changes

During the Solution Design Phase, the WA module team identified the following as major process changes designed to stay consistent with the CHRS Guiding Principles:

The “Reports To” field on Position will reflect the organizational structure of CSU. The direct supervisor for the position will be stored in the field.
Position Number will be systematically assigned based on the next sequential number from a counter on the Installation Table. No smart coding will be used.
The team made a recommendation as to when to add a new Position or re-use an existing inactive Position:
New Positions will be created when no inactive position with the same Department and Job Code exists.
Positions will be re-used if the position is inactive and has the same Department and Job Code.
This recommendation should not be confused with refilling an existing position where the incumbent resigned.
Campuses will capture the Social Security Number (SSN) and birthdate for POIs.
Four new Employee Classes will be added and three will be inactivated. Campuses should begin to use these with the implementation of CHRS:

Added

Interim Appointment
Immediate Pay/Rehired Annuitant
Temporary/Rehired Annuitant
Temporary 3 Yr/Rehired Annuitant - Inactivate
Leaver
Non-Employee
Promotee
The WA Solution Design team recommends adding New Action/Action Reasons listed below. The position action/action reasons will be used in Position and will also be updated to Job Data. New PIMS mapping will be determined prior to implementation of CHRS and will be programmed into the PPT.
POS/RTT for Title and Reports To Change
POS/RPT for Reports To Change
HIR/XFR (for Transfer from another CSU Campus)
TER / XFR (for Resignation - Accepted position, move to another CSU)
XFR / PRM (for Temp Reassignment to Perm Reassignment) - PIMS 416
PRO/APR: Promotion - Temp to Prob/Perm Appt - PIMS A50
PAY/TDG (for Lecturer achieves terminal degree/grade increase per Memorandum of Understanding (MOU))
DTA/PRI - Update Job Indicators
To ensure the 125% rule is adhered to, campuses will use delivered functionality in Job that produces a warning message when an employee's FTE in all active employee records is more than 1. The Temp Faculty modification to will require an additional modification to ensure the 125% rule is enforced.
Employee ID (Emplid) will be assigned by the system using the next available number from a counter on the Installation Table.
Employee Record Number (ERN) will be assigned by the system as the next available number.
Company Seniority date field on the Employment page will be used to calculate Employee Service Awards. Campuses will still use their specific calculation method for the Service Awards but the beginning date will be tracked in the Company Seniority date field.
As a best business practice, it is recommended campuses will keep position and job in sync where the positions and job are 1 to 1. This can be done using either the Update Incumbents check box or an audit report.
The Reports To field on Position Data will reflect the organization structure.
The Primary Job Indicator will be determined based on the criteria listed below. The Primary Job Indicator will be maintained by a custom program that will be run at least one time daily.
HR Status = A and Per Org = EMP
Hierarchy of Employee Class (Reg, Acting, PRTB, FERP, Temp 3 Yr, Temp, Intermittent, Rehired Annuitant, Emergency, Immediate Pay, Student)
If all ERNs are same Employee Class, then highest FTE
If all ERNS are same FTE, then earliest hire date
If all ERNS are same Hire Date, lowest Employee Record number
Job Stacking at the Campus Level - Staff and MPP
Job Stacking Student Worker Records
Job Stacking Special Payment Types
Campuses should not be using non-employee tracking, Job Code (0051) in CHRS. It is not needed for Academic Planning Data Base (APDB) reporting as previously assumed.
Campuses should use the delivered pages to track employees who telecommute.
Telework eligibility will not be tracked at the Job Code or Position level.

1.5 Modifications

1.4.1 Retired Baseline Modifications

The following represents the list of baseline modifications that were retired because they were no longer needed and/or the functionality was replaced by delivered 9.2.

Mod #	Modification Name
HR09004	CSU Furlough Implementation
HR99034	Enable FTE Field
WA14005	VEVRAA and Section 503
CC99004	Marital Status
HR05005	Benefit Mods to Job Data
WA14006	Personal Data Audit Scripts
CC99002	Ethnic Group

1.4.2 9.2 Modification Requests

All modification requests (whether a new request or baseline modification carrying forward), were required to be submitted as a Gap Resolution Process (GRP) request. There are a total of 29 GRPs recommended by the Workforce Administration Solution Design Team. Of these, 29 are software modifications requests and 0 are policy change requests. For the full list of GRP submissions, including the description and type, please see Workforce Administration table in Appendix A.

2.1 Temporary Academic Employment

CSU Temporary Academic Employment (TAE) is a CSU-delivered, custom module used for the “management” of TAE. This includes the entry of Temporary Faculty appointment data for creating appointments and functionality to print TAE appointments; automatic loading of TAE transactions into Job Data; and CSU TAE reports to assist in the management of TAE data.

2.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Temporary Academic Employment (TAE) Solution for the CSU:

Security at the department level will remain the same with Temp Academic Employment module for CHRS.
Data Entry for assigned time, faculty courses, etc. will continue to be handled in Student Administration.
Existing Temporary Faculty Setup Tables will continue to function the same. There are some additions to the setup as submitted in GRPs.
Future Hire POI type will still be needed for TAE as well as synching between emplids.
Existing TAE functionality in the baseline mod was replace with a complete redesign in July 2019 as indicated in submitted GRP's.
All existing reports in the TAE module will continue to be available in PS real time and majority will be carried over to Data Warehouse (DW). The only reports that will not be brought over to Data Warehouse should be the Student Administration specific reports since the data does not exist in the DW.

2.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.

Implement custom AW (Approval Workflow) for automated Temporary Academic Employment approvals. We recommend implementing custom workflow automation for routing and approvals.
Self-Service for employees to review appointments, decline and complete additional information needed for appointment processing.

2.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in Workforce Administration Solution Design.

ID	Business Process Flow
90	90 Temp Faculty

Major Process Changes

During Solution Design phase, the TAE Module team identified the following as major process changes designed to stay consistent with the CHRS Guiding Principles:

Entering Appointment Data for Temporary Academic Personnel into the TAE module for additional persons such as Instructional Student Assistants (ISA), Substitute Faculty, Music Studio Faculty, Substitute Teacher Assistants, Temporary Librarians, Counselors and Coaches will be a major change for all campuses including those that do currently use the existing baseline module.
Current and future Temporary Academic Employees will also need to be trained and understand how to review and complete information in self-service.
Since automated workflow routing and approvals will be incorporated into the module, training will need to take place to ensure administrative personnel are submitting, processing and reviewing transactions in a timely manner for employee notification/review and payroll processing.
Setup tables may need to be updated with changes due to the consolidation of all campuses into one environment. This will impact both new and existing users since additional configuration will need to take place prior to use of the TAE module.
New/existing reports for the TAE module may be available the Data Warehouse. Since the Data Warehouse is new to everyone, we will need to ensure the appropriate training and guidance is in place to review the TAE existing and new reports to aid in processing/audits.
All campuses will be required to use the Temporary Academic Employment module.

2.5 Modifications

2.4.1 Retired Baseline Modifications

The following represents the list of baseline modifications that were retired because they were no longer needed and/or the functionality was replaced by delivered 9.2.

Mod #	Modification Name
NONE	NONE *

*Much of the 9.0 Baseline modifications for Temporary Academic Employment will not be carried forward. The module was completely redesigned.

2.4.2 9.2 Modification Requests

All modification requests (whether a new request or baseline modification carrying forward), were required to be submitted as a Gap Resolution Process (GRP) request. There was a total of 6 GRPs recommended by the Workforce Administration Solution Design Team for Temp Academic Employment. Of these, 6 are software modifications requests, 0 are policy change requests. For the full list of GRP submissions, including the description and type, please see Temporary Academic Employment table in Appendix A.

3.1 Benefits Administration

CSU Benefits Administration (BenAdmin) is a rules-based system, configured to process and track CSU benefits eligibility and enrollment information, including: Employee Health, Dental, Vision, Life, Disability, Health Flexible Spending, Dependent Flexible Spending, COBRA, and Retiree Dental. The CSU Benefits system contains employee and dependent information as required to the determine eligibility and enrollment in benefit plans. Electronic interfaces manage the transmission of enrollment data to Delta Dental, SCO and CalPERS Systems. Base Benefits provides the core configuration for benefit plans, rates, and programs. Benefits Administration utilizes this foundation table setup and provides the automation necessary to determine eligibility, apply event rules and definitions, utilize geographic location, control effective dates, and manage data processing. With Benefits Administration implemented, the system writes all enrollment rows into the Base Benefit tables. Every data entry change processed in job and geographic location is analyzed by benefits administration to determine the effect on current or future enrollments and eligibility status.

3.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Benefits Administration solution for the CSU:

Campuses are current with managing BAS events. Benefits Administration processes one event at a time, in sequential order, per employee. When events are not closed properly subsequent events will not open. Therefore, campuses must audit for open events prior to running Open Enrollment for the first time and resolve/close prior events.
All Position papers have been completed and where applicable are part of current business process before campus implementation.
Campuses currently have, or will be able to put in place the best practices and processes required to support PeopleSoft Self-Service.

3.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.

eBenefits is enabled to provide employee access to self-service for enrollment in benefits.
Life Events in self-service provides a guided process for employees to initiate a change to their benefits due to a specific life event such as birth, adoption, marriage, and divorce.
Activity Guides can be used for specific CSU Life Events and provide step-by-step instructions for completing the specific task such as birth, adoption, marriage, and divorce, late enrollment and parent-child relationship.
Fluid pages in core and in Employee Self-Service (ESS) are available in 9.2. Fluid pages use tiles rather than menu options and are designed to fit on mobile devices.

Following features are still pending design and configuration and will not be part of Release 1.

Document attachment feature is included in the life event process to enable employees to upload files that support the benefit change such as birth certificates or marriage licenses.
COBRA processing automates the search to identify qualifying events and the employees and dependents that are eligible for COBRA benefits, including termination of employment, loss of eligibility for employees or dependents, and overage dependents. Notifications can be generated to provide all required regulatory and CSU information for COBRA benefits and rates.
Extended Leave Framework is new functionality that builds on the foundation tables of Absence

Management and provides a separate area to enter and manage extended leave requests such as Family Medical Leave. The module includes employee self-service for requesting leave, document attachments, eligibility validation, tracking hours, and reporting status.

Leave Donation functionality allows an employee to donate their accrued leave hours to another employee. Employees make donations and request donated leave via employee self-service.
Work Centers can be configured to provide links to pages, reports and queries in one place

3.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in Benefits Administration Solution Design.

ID	Business Process Flow
41	Manage COBRA Events
42	Open Enrollment (Full Self-Service Campus/View Only Campus)
43	New Hire – Newly Eligible Benefit Enrollment (Full Self-Service Campus/View Only Campus)
44	Tuition Fee Waiver
47	Workforce Admin - Initiate or Change Enrollment
48	Life Event Enrollment (Full Self-Service Campus/View Only Campus)
49	Manage Extended Leave
490	Manage Leave Donation

Major Process Changes

During the Solution Design Phase, the BenAdmin module team identified the following as major process changes designed to stay consistent with the CHRS Guiding Principles:

Benefits Administration Event Maintenance will be run centrally for each campus on a scheduled basis.
All Benefits configuration is maintained centrally (except the CSU Benefits Officer Table).
Employees will complete enrollment elections in eBenefits.
To support the implementation of self-service, automation to enter permitting event codes is proposed. Staff will not be required to enter CalPERS codes for every corresponding event.
Employees will initiate most Life Events online.
Multiple events exist to control self-service features and audit transactions. Staff will utilize specific event codes as applicable and reduce the use of the all-encompassing HBE.

Note: Some flexibility is provided within the common business process for benefits. While eBenefits is recommended for CHRS, campuses that do not maintain the infrastructure required for self-service may continue to collect an enrollment form but are strongly encouraged to work toward self-service. Campuses will have the option to implement eBenefits Full self-service OR eBenefits View-Only self-service.

3.5 Modifications

3.4.1 Retired Baseline Modifications

The following represents the list of baseline modifications that will be retired because they are no longer needed and/or the functionality will be replaced by delivered 9.2.

Mod #	Modification Name
BA15001	Auto Waive components of CSUBAS (CSU_AUTOENR1 and CSU_AUTOENR2)
BA05007	Search View for event status update
BenRcdNbr	Changes the Benefit Record Number to 1 for benefit ineligible job codes
BA05009	Benefits Administration Conversion
BEN1501	ACA IRS reporting

3.4.2 9.2 Modification Requests

All modification requests (whether a new request or baseline modification carrying forward), are required to be submitted as a Gap Resolution Process (GRP) request. There was a total of 29 GRPs recommended by the Benefits Solution Design Team. Of these, 27 are software modifications requests, and 2 are policy change requests.

For the full list of Benefit GRP submissions, including the description and type, please see Benefits Administration table in Appendix A.

4.1 Time & Labor

Time and Labor (TL) is the time tracking and processing module for all non-exempt employees to create the

Payroll Input Process (PIP) file to produce an employee paycheck. Time is tracked using third-party Time Collection Devices (TCD), Employee Self-Service (ESS) Timesheets, Web Clocks and Rapid Time for employees using paper timesheets. Time entered is validated and processed to create payable time. Information types that are tracked, processed and maintained are: time worked, overtime, shift premiums and task reporting. The module is dependent on Workforce Administrative and Core Security. TL leverages Approval Workflow (AW) to process approvals. This is an alternative option to traditional workflow and provides more configuration options to complete very complex business requirements. TL integrates with Absence Management (AM) to collect absence data. Ultimately, the data from AM and TL is sent to the State Controller’s Office (SCO) and processed by the Payroll Input Management System (PIMS) to produce employee paychecks.

4.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Time & Labor solution for the CSU:

Auto Enrollment process is configured to correctly assign Time Reporter Data, if eligible. CMS will deliver some "starter" queries and Workgroups that can be leveraged by Auto Enrollment at a given campus. Campuses will then be given the ability to change or add to the queries and Workgroups on an as needed basis. Campuses will be required to support their own custom solutions.
Assign Schedule if eligible, will only be processed at time of hire.
Job Data, the source for all criteria to determine Auto Enrollment processes, is correct and timely.
Payable time approval uses the employee’s Reports To field in their Job Data or Dynamic Group as the approver whichever is selected by the campus.
Dynamic Groups (DG) are required for row level security.
Payable Time approvals will only be used. Real time rules will generate payable time on the submission of the timesheet.

4.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.
1. Auto Enrollment: Replaces very common and complex customization to create/maintain Time Reporter Data and set user preferences.
2. Real Time Rules: Allows Time Administration to be executed from the online timesheet. This reduces the amount of time for a batch Time Administration run and users will know immediately any issues with their time with the ability to resolve in a timely manner.
3. TRC Program Filter: Configure TRCs to not appear on timesheet for employees, but to be accessible by Manager or Administrator Roles.
4. Update ECD and TR Status: Update Earliest Change Date (ECD) and Time Reporting (TR) status. These are factors Time Administration uses to determine the date to begin processing an employee’s reported time. There is a new online page to update for time reporters. This page is efficient and flexible.
5. Expanded Timesheet Controls (Workgroup): Configurable Legal Statement for ESS and MSS Timesheets. ESS and MSS entry points can have different Legal Statements. There will be standard language for all campuses.
6. Fluid User Interface (UI): User Interface for mobile devices (cell phones and tablets) for using PeopleSoft applications is optional on personal devices.
Approval Workflow (AW) replaces traditional (non-AW) workflow approvals. Framework that completes most customer business requirements for processing approvals in many HCM modules. Highly configurable to complete very unique business requirements.
TL WorkCenter: One-stop shop for users to complete TL processes to be more productive and create a better user experience. Framework can be configured for individual user needs with Pagelet functionality.
TL Dashboard: Similar to TL WorkCenter for Supervisors to monitor and complete TL tasks.

4.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in Time & Labor Solution Design.

ID	Business Process Flow
70	Enroll Time Reporters - New Hire
72	Review Schedule
73	Assign and Update Schedule
74	Time Entry
75	Time Entry, Approvals, Exceptions
76	Compensatory Time Off
77	Overtime Request
78	Payroll Interface Process
79	MPC
80	Additional Pay

Major Process Changes

During the Solution Design phase, the Time & Labor Module team identified the following as major process changes to stay consistent with the CHRS Guiding Principles:

Auto Enrollment will replace campus customizations to maintain Time Reporter Data (TRD). This includes assigning schedules and setting time reporting user preferences.
Employees will report their own time using a punch or elapsed timesheet, web clock or time collection device (TCD). Rapid time entry will continue, but the expectation is the volume will be lower due to the shift to more ESS time entry.
The Approval Workflow (AW) is replacing traditional workflow. The employee’s REPORTS_TO field in their Job Data or Dynamic Groups is the approver.
No reported time approvals will be configured. This impacts mainly Students. Payable Time approvals will only be used. Real time rules will generate payable time on the submission of the timesheet.
CMS will schedule Time Administration to run twice per day for all campuses. Campuses can run ad hoc as needed.
Time Administration – Real Time Rules (RTR) will be turned on and executed with the Submit button.
Campuses will have the ability to override funding data using Task Configurations. The elapsed timesheet and web clock will have additional fields to enter Task Profile information.
CMS will have a process to allow campuses to request new pre-defined schedule. This will reduce the number of duplicate schedules.
Four processes currently completed in Absence Management will now be completed in TL using Compensatory Time Off (CTO) functionality. The employee will enter their takes into the timesheet. Earns will be entered by the user, timekeeper, payroll or created by a custom rule depending on the CTO plan.

4.5 Modifications

4.4.1 Retired Baseline Modifications

The following represents the list of baseline modifications that were retired because they were no longer needed and/or the functionality was replaced by delivered 9.2.

Mod #	Modification Name
TL05001	CSU TL Rules
TL07001	CSU Time Reporter Update Process
TL07002	Las Name, First Name display
TL10001	Integrations Links in Self Service
TL14001	Time and Labor ACA Reporting

4.4.2 9.2 Modification Requests

For the full list of GRP submissions, including the description and type, please see Time & Labor and Absence Management and Time and Labor tables in Appendix A.

5.1 Absence Management

Absence Management (AM) is a rules-based system. It is being designed to process CSU leaves: sick, vacation, personal holiday, bereavement, etc. This system will become the system of record for tracking all leave types at the CSU which are not required to be tracked on either the job record or through an extended leave process. It will be designed to focus on allowing employees to enter their own leaves through self-service with the associated approval process being handled by the Approval Workflow (AW).

AM functionality in CHRS will leverage new PeopleSoft v9.2 features as delivered by Oracle. Where native

PeopleSoft functionality falls short of CSU’s business needs and a business process/processes cannot be altered, approved modification(s) will be developed to correct the business shortfall. As CHRS is being built to support multiple institutions in a single database, multi-institution security has been developed to ensure users only have access to data of the employees employed at their respective campus.

5.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Absence Management solution for the CSU:

Campuses will only have access to their own employees’ data in the absence system.
- Campus staff will be responsible for ongoing monitoring of employee absences.
Non-MPPs will be able to approve absences.
Campuses will be able to create and maintain their employees’ job data.
The absence management system will be moved to a “request” system whenever possible.
All employees will have a work schedule assigned in the system.
- Predefined work schedules will be created and maintained by CMS, but assigned either by TL auto-assignment or campus manual effort.
All campuses will have the same pay date for positive pay employees.
The absence conversion process will convert all current absence balances in to the production system.
- Absence history must be made available in your static 9.0 instance.
Absence management will be the system of record for tracking both paid and unpaid absences at the CSU with the exception of the FMLA types.

5.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.

The Fluid User Interface will be leveraged for Absence Management self-service.
Approval Workflow will be leveraged for absence approvals.
The Absence Event Table will be audited in order to monitor and report on activity.
Work Centers will be built to facilitate employee, manager, and timekeeper role in regards to absence.
Forecasting will be used to assist employees to determine whether or not they will have an available balance to take leave.
- It will also be used to validate that the correct data has been entered into the system.
The delivered Cancel / Modify Absences function will be leveraged to allow employees better control over their absence system.
- Employees and approvers will be able to cancel any absences which have not been finalized.
- Finalized absences will be able to be voided by payroll staff.
Retroactivity for 12 months will be turned on.
Employees will be able to enter absences up to 12 months in advance and 12 months prior.

5.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in AM Solution Design.

ID	Business Process Flow
031	AbM_Absence Enrollment
032	AbM_ Absence Request EE/Manager/Timekeeper
033	AbM_Absence Request - Absence Administrator
034	AbM_Cancel/Modify Absences EE/Manager/Timekeeper
035	AbM_Cancel/Modify Absences - Absence Administrator
036	AbM_Administer Absence Calculation
037	AbM_Manage Absence Transfers
038	AbM_Leave Donations
039	AbM_Manage Extended Absence
300	AbM_Absence Entry - Administrator
305	AbM Work Schedule Assignment -- Bolt-On

Major Process Changes

During the Solution Design phase, the Absence Management Module team identified the following as major process changes designed to stay consistent with the CHRS Guiding Principles:

The mass HR notification process will be leveraged by campuses to communicate with targeted groups of users rather than a custom solution.
Employee Self-Service will be the preferred method of entering absence data in to PeopleSoft.
The Timekeeper Review functionality has been changed to better leverage the delivered system. The functionality remains the same, but the pages involved will be different.
The Absence Management system will be moved to a “request” system whenever possible.
All campuses and paygroups will be processed on a single calendar group.
- The calendar group will be finalized on the 5^thbusiness day of each month with no exceptions.
- Retroactivity will be used to cover any late entries.
- The calendar group will be open throughout the month and calculated nightly.
- Campuses will be responsible for generating the academic periods and calendars for their ACD paygroup.
- These calendars will be added by a central group to the master calendar.
All Absence Elements (including Paygroups) will be created and maintained centrally.
Self-Service functionality will be made available to all absence-eligible employees.
- Campuses will be able to determine how best to serve employees who do not have regular access to computers.
Approvers will be able to use self-service to enter and approve absences on behalf of employees.
The Reports To field or Dynamic Group, based on campus decision, will be leveraged to hold the absence approver.
The Manager ID field on the Department Table will be used to hold the person with fiscal responsibility for the department.
- This field will not be overridden by data from Common Financial System (CFS).
Retroactivity will be turned on in the Absence Management module.

5.5 Modifications

5.4.1 Retired Baseline Modifications

The following represents the list of baseline modifications that were retired because they were no longer needed and/or the functionality was replaced by delivered 9.2.

Mod #	Modification Name
AM13001	CSU Association Bank
AM10006	Absence Self Service – Mass Notifications
AM10005	Alternate and Proxy User
AM10004	Prior Period Absence Process
AM10003	Absence Self Service Security
AM10001	Report and View Absence Page
AM06002	Increase Cobol Array Sizes
AM06001	Absence Conversion

5.4.2 9.2 Modification Requests

All modification requests (whether a new request or baseline modification carrying forward), were required to be submitted as a Gap Resolution Process (GRP) request. There was a total of 21 GRPs recommended by the AM Solution Design Team. Of these, 10 are software modifications requests and 11 are policy change requests. For the full list of GRP submissions, including the description and type, please see Time & Labor and Absence Management and Absence Management tables in Appendix A.

6.1 LCD

The primary goal for Labor Cost Distribution (LCD) in CMS Baseline is to transmit a CSU payroll expenditure journal from the HCM application into CFS.

6.2 Key Assumptions

The following are key assumptions made in the design of the CHRS Labor Cost Distribution solution for the CSU:

While the SCO Pay Tape Load into LCD may be centralized, the monthly LCD processing will NOT be centralized. Each campus will continue to do their own LCD processing.
All campuses will do their budgeting and funding setup for chart of accounts field values in the CFS instance.
All campuses will run the CSU Publish LCD Data to FIN process (CSULCD70) so that their CSU_LABOR_DIST reporting data gets copied into the CFS instance for Budget reporting.
All campuses will use the same CSU Pay Tape Period format of “yyyymm” (e.g. 201706).
If San Diego does not implement CFS before implementing CHRS, then custom run control pages will need to be developed so that San Diego can continue to run their three custom LCD programs that do NOT integrate with CFS (CSU Export Accounting Lines, CSU Publish LCD Data to FIN, & CSU ESP Programs).

6.3 New Functionality

Features listed below are new CSU modifications for CHRS or delivered in a PUM by Oracle in 9.2.

New Budget Expenditure reports for Actuals and Projections will be available in the CFS Data Warehouse, provided the campus copies their CSU_LABOR_DIST reporting data to the CFS instance.
Adding campus-defining field (BUSINESS_UNIT_PC) to ACCT_CD_TBL will allow Combo Code Build process, Combo Code Fiscal Year Rollover process, and the Combo Code Sync process to work in CHRS.

Following feature while not part of CHRS will be available via from the SCO.

The ability for an employee to view their paycheck via access Self Service will be access through the SCO CEC (Cal Employee Connect) for CHRS.

Following feature are still pending design and configuration and will not be part of Release 1.

Prior to running the CSU Actuals GL Interface process, campuses will run a new GL Interface Audit report to identify and correct any errors the GL Interface process may encounter.

6.4 Business Process Flows and Major Process Changes

Business Process Flows

The following represents the list of business process flows covered in the LCD Solution Design.

ID	Business Process Flow
95	Labor Cost Distribution Monthly Processing

Major Process Changes

During the Solution Design phase, the LCD Module team identified the following as major process changes designed to stay consistent with the CHRS Guiding Principles:

Receive a single monthly Pay Tape file from the SCO and load it centrally by the CO into PeopleSoft. Then each campus will retrieve their data from a master record in PeopleSoft.
Centralized Job Codes and Deduction Codes: For these configuration tables, campus data will be standardized and converted then centrally managed by the CO
All “split” funding (funding for a cost from more than one funding source) and “grants” funding will be setup and defined on the Department Budget Table.
Currently, LCD Expenditure Adjustments by Employee process only allows adjustments for a single charge period. A modification to allow the LCD Expenditure Adjustments by Employee process to process multiple charge periods has been recommended. This modification would replace the need for a Lump Sum Adjustment process.

6.5 Modifications

6.5.1 Retired Baseline Modifications

The following represents the list of baseline modifications that were retired because they were no longer needed and/or the functionality was replaced by delivered 9.2.

Mod #	Modification Name
BE99001B	CSU Department Budget Adjustment
BE99001H (partial)	CSU Payroll Messages report (removing just this report and its associated objects from this modification – everything else in this modification will be migrated to CHRS)
BE05001 (partial)	CSU TL Combo Code Override page (removing just this page and its associated objects from this modification – everything else in this modification will be migrated to CHRS)
BE04001 (partial)	CSU Blanket Serial Xlat Values page (removing just this page and its associated objects from this modification – everything else in this modification will be migrated to CHRS)

6.5.2 9.2 Modification Requests

All modification requests (whether a new request or baseline modification carrying forward), were required to be submitted as a Gap Resolution Process (GRP) request. There was a total of 10 GRPs recommended by the LCD Solution Design Team. Of these, 10 are software modifications requests and 0 are policy change requests. For the full list of GRP submissions, including the description and type, please see LCD table in Appendix A.

7.1 Recruiting

A new Recruiting Solution was selected to better meet the CSU’s need to attract and hire excellent candidates, ensure operational efficiency, and includes robust Data Analytics. This system provides campuses with great flexibility in designing their recruitment processes. It is a cloud solution built in PageUp. Integration between PageUp and the HCM application is available now (PeopleSoft 9.0.). This integration will be moved forward to PeopleSoft 9.2.

7.2 Guiding Principles Used for the solution selection:

Provide a paperless, end-to-end recruiting process from the initial “Request for Hire” to the “Manage Hire process”.
Provide standardized recruiting processes and practices where possible, but allow maximum, flexible campus options to support campus specific business needs and campus branding.
Develop comprehensive recruiting requirements to support both staff and faculty functions.
Engage stakeholders. Stakeholder engagement and inclusion is a critical component of the CSU culture to ensure buy-in, adoption and ownership of the recruiting solution by our campuses.

7.3 Key Assumptions

A campus will be Live on Recruiting built by PageUp before implementing CHRS Release 1.

7.4 Scope

CSU Recruitment process (core and campus flexible) for Faculty:
- Full Time Faculty (Probationary / Tenured, Temporary) o Part Time Faculty (Temporary) o Visiting faculty (FT Temporary) o Head Coaches (FT Temporary) o Counselors (Probationary / Tenured, Temporary) o Librarians (Probationary / Tenured, Temporary) o State-Support Instructional Summer Faculty
CSU Recruitment process (core and campus flexible) for Staff:
- Represented staff o Emergency hires o Management (MPP) o Execs/VP
3CSU Recruitment process for Student:
- Represented Students: Graduate Assistant (GA), Teaching Assistant (TA)

8.0 Appendix A: Gap Resolution Requests

8.1 Legend – Software Modification Types

Modification Type	Explanation (paraphrase)
Bring forward existing baseline mod	Straight retrofit. No changes to existing 9.0 baseline functionality.
Change to existing baseline mod	Enhance and/or fix problems that currently exist in the 9.0 baseline functionality before moving to CHRS.
New Mod	Brand new functionality
Bring forward existing campus mod (tech specs required)	Campus submits existing documentation on their campus mod. CMS will either leverage the campus’ design (most likely) or retrofit the campus mod itself for CHRS (less likely).

8.2 Workforce Administration

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
25	WA Conflict of Interest	CSU Campuses must comply with state law pertaining to the Conflict of Interest (COI) disclosure process of the Fair Political Practices Commission, Political Reform Act, Government Code Sections 81000, et seq. Specific requirements are set forth in technical letter HR2003-03. COI filing is an annual campus responsibility.	Software Modification	☒ New Mod	Release 1
56	WA Job Search	Delivered search page does not contain all of the necessary data elements for identifying and distinguishing one employee record from another when an employee has multiple job records on one campus and/or system wide.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
61	WA Hire Dates	Delivered Job Data pages do not contain the necessary CSU specific date fields (i.e. PeopleSoft delivered field Original Hire Date functions differently than the CSU requirement for item 921). Maximizes reporting capabilities, ensures accurate data for compliance with CSU/CFA CBA, and reduces manual effort using multiple systems.	Software Modification	☒ New Mod	Release 1
69	WA Student Employment	Delivered functionality does not include required data elements, has limitations for a decentralized process, and does not allow for mass hiring (batch). Campuses will have to process thousands of transactions manually via paper documents and key each transaction individually into the system. In addition, the delivered process in Job Data requires navigating through numerous pages and elements on each page which would take more time per transaction.	Software Modification	☒ New Mod	Release 1
79	WA CSU Position	Additional data is required in Position for the CSU integration with the PIMS and for system wide tracking requirements, such as MPP codes.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
80	WA CSU Job	The CSU Job modification includes fields and functionalities that were defined in prior versions as required for the CSU business processes. This modification addresses the requirements to interface with the PIMS as well as requirements for faculty processing and tracking. Additionally, fields in CSU Job are used for system wide reporting.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
123	WA Primary Job Indicator	Job Indicator field is set to ‘Primary Job’ when an employee is first entered into the system. Any concurrent job entered into in the system inserts ‘Secondary Job’ into the Job Indicator field. With the implementation of a singular database across the system, campuses are requesting a nightly process be developed to consistently set Primary and Secondary Job flags for employees with non- volunteer job rows for each Business Unit.	Software Modification	☒ New Mod	Release 1
127	WA CSU Faculty Action	Since the data must be captured in order to respond to regulatory reporting requirements (i.e., IPEDS), and must be tracked to comply with CSU policy on retreats rights, campuses will have to develop and maintain a separate system (i.e., excel) to track all of the data elements manually, outside of PeopleSoft if the modification is not approved. This will result in lack of consistency and accuracy of data reported system-wide.	Software Modification	☒ Change to existing Baseline Mod	Release 1
137	WA Person Org Summary Additional Fields	Staff processing transactions from Manage Hire into Job Data need to see which job records to use. Without it they have to navigate outside the process to confirm the correct action and job record prior to proceeding. If Manage Hires were not used at all, then the function to close recruitments would have to be performed manually. Using the Manage Hire tool returns an automatic closing record to the	Software Modification	☒ Change to existing Baseline Mod	Release 1
139	WA Employee Opt Out of Union Reports	Ability for employees to self-report if they wish to opt-out of having their personal information (home address, telephone, etc.) shared with unions. • Ability for an HR administrator to manually update the “opt-out” selection identified by an employee. Ability to run an adhoc query or report from the data warehouse that would successfully exclude those employees who “Opt-Out” of sharing personal data with the unions.	Software Modification	☒ New Mod	Release 1 -Modified no self service
140	WA - Pay Check Designee	• The employees will be required to indicate their pay warrant designee on a paper form, which is then filed in a personnel and/or payroll file. This is normally done at the time of hire and there is opportunity for this not to be updated timely, especially in the event of death or divorce of the designee. For example, without an update form in the event of a divorce, the final pay warrant would be issued to a former spouse.	Software Modification	☒ New Mod	Release 1
142	WA PPT mod	• As part of the business practice analysis we timed how long it would take to look up the mapping code from PeopleSoft to PIMS for each data field in a sample of transactions that are entered into the State Controller’s Office (SCO) System. Currently the fields are populated on the PPT Form, manual lookup for each field for each transaction takes from three to seven additional minutes per transaction. Campuses complete thousands of transactions each semester. Changing the current CSU Business Practice would require hundreds of additional hours of manual effort.	Software Modification	☒ Change to existing Baseline Mod	Release 1
155	WA ID Management	A current CMS modification (WA12001) is being used across the system to lump employees into 3 broad categories for potential usage in single sign-on and other system-wide projects and initiatives. There are subsets of categories that are affiliated with these 3 broad categories.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
156	WA Salary Schedule Load Interface	A modification to baseline currently exists to load changes in the salary schedule from a source file provided by HR-ISA (SCO – State Controller’s Office) to the baseline tables. This provides timely updates to tables that are used by all campuses. In addition, extra fields have been added to the Salary Grade Table to capture CSU specific information.	Software Modification	☒ Change to existing Baseline Mod	Release 1
157	WA CSU Transactional Front End	If this modification is not approved, campuses will use the modifications requested in WA Student Employment, WA Temp Faculty Mod GRP’s if approved, to process Temp Faculty and Students. All other employee transactions will have to be processed manually, which will be a significant impact on campus staffing and the accuracy of data since the majority of campuses have a custom solution of varying degrees.	Software Modification	☒ New Mod	Release 1
161	WA CSU Refresh Employees Table	PeopleSoft delivers a table called “Employees” for reporting purposes that combines active employee data elements. In order to meet CSU’s business requirements, additional fields were added to the Employees Table. These are CSU custom fields from the CSU_JOB record – a custom record. In addition, it provides Ethnicity values correctly.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
162	WA IPEDS REPORTING	This existing modification initiated by CSU HRM provides a solution for the federal IPEDS regulatory reporting requirement. Without this baseline modification, the CSU will still need to meet this requirement.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
163	WA SSI GSI Prob to Perm	Without this modification campuses will have to manually process thousands of transactions individually into PeopleSoft to match the values updated in PIMS.	Software Modification	☒ Change to existing Baseline Mod	Release 1
164	SWHWA CSU Ethnicity	HR/Personnel tech letter 2010-01 requires campuses to track a subset of ethnicities/races for reporting purposes. This functionality is not on Oracle’s	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
166	WA CSU ID Search	Campuses request this modification be brought forward to assist in Empl ID identification to avoid creating duplicate Empl ID's.	Software Modification	☒ Change to existing Baseline Mod	Release 1
167	WA Job Data Validation	Without this modification, campuses would have to manually validate every transaction for thousands of temporary employees. In addition, campuses would have to manually validate the action_reason code for every employee transaction which could potentially cause issues with mapping to PIMS.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
168	WA Emergency Contact	Without this modification, campuses will continue to use or seek out third party products to capture data, which will prevent CSU system-wide access to the emergency contact information. PSFT does not deliver all of the necessarily data elements and functionality to facilitate maximum employee exposure to the emergency notification.	Software Modification	☒ New Mod	Release 1
170	WA Employee Review	PSFT does not deliver all of the data elements to meet the CSU requirements for tracking evaluation cycles and the outcomes. If this modification is not approved, each campus would be required to use an external system to track the receipt of employee reviews and capture overall ratings. This information would need to be joined with PSFT to determine if temporary faculty received an unsatisfactory review at the time of appointment, if MPP received an unsatisfactory review and were not eligible for general salary increase and each bargained employee received performance appraisal based on a ppl i cabl e CBA articles.	Software Modification	☒ Change to existing Baseline Mod	Release 1
196	WA Interim SSN	Employees who are in the process of obtaining but do not as yet have a valid Social Security Number (SSN) at the time of the hire will be assigned an interim SSN by the SCO agent per the PIMS manual and SCO agent business process. This requirement tracks a unique number in place of the SSN that identifies the PIMS employee as the PeopleSoft employee for LCD purposes until a valid SSN is updated.	Software Modification	☒ Change to existing Baseline Mod	Release 1
197	WA CSU Job Group	System-wide Human Resources at the Chancellor's Office maintain and manage the CSU Salary Schedule. It is required that the tracking of the FLSA status and the Affirmative Action code is assigned by the Salary Admin Plan/Salary Grade not by Jobcode as delivered by PeopleSoft.	Software Modification	☒ Change to existing Baseline Mod	Release 1
81	WA POI Reports	POI values are in use to track Future Employees, Auxiliary employees, Volunteers, Emeritus, etc. These values allow campuses to have active EmplIDs and facilitate access to campus amenities, training, etc. Campuses have individual processes to report on these. The CO needs to report on Volunteer Faculty across all campuses per agreement with CFA. POI appointments have Business Units, Department affiliations and Expected End Dates and need to be entered, updated, and separated as appropriate. A Data Warehouse solution is needed to enable reporting.	Software Modification	☒ New Mod	Roadmap
83	WA Address Validation	Addresses are a determining factor in benefit plan eligibility. In a system where employees can enter and update their own address, it is important to have a mechanism to ensure that addresses are accurate to ensure accurate benefit plan selection and benefit documents are received by employees. PeopleSoft does not deliver an address validation tool and address validation is not on the Oracle road map.	Software Modification	☒ New Mod	Roadmap
106	WA Restrict Business Phone	PS 9.2 does not deliver the necessary controls on the business phone field to meet CSU standardization requirements or EO 1056.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
147	WA RTP Modification	The delivered functionality does not include the required data elements nor does it track all required data elements in one location to administer the Retention, Tenure,	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
166	WA CSU ID Search	Campuses request this modification be brought forward to assist in Empl ID identification to avoid creating duplicate Empl ID's.	Software Modification	☒ Change to existing Baseline Mod	Release 1
167	WA Job Data Validation	Without this modification, campuses would have to manually validate every transaction for thousands of temporary employees. In addition, campuses would have to manually validate the action_reason code for every employee transaction which could potentially cause issues with mapping to PIMS.	Software Modification	☒ Bring forward existing Baseline Mod	Release 1
168	WA Emergency Contact	Without this modification, campuses will continue to use or seek out third party products to capture data, which will prevent CSU system-wide access to the emergency contact information. PSFT does not deliver all of the necessarily data elements and functionality to facilitate maximum employee exposure to the emergency notification.	Software Modification	☒ New Mod	Release 1
170	WA Employee Review	PSFT does not deliver all of the data elements to meet the CSU requirements for tracking evaluation cycles and the outcomes. If this modification is not approved, each campus would be required to use an external system to track the receipt of employee reviews and capture overall ratings. This information would need to be joined with PSFT to determine if temporary faculty received an unsatisfactory review at the time of appointment, if MPP received an unsatisfactory review and were not eligible for general salary increase and each bargained employee received performance appraisal based on a ppl i cabl e CBA articles.	Software Modification	☒ Change to existing Baseline Mod	Release 1
196	WA Interim SSN	Employees who are in the process of obtaining but do not as yet have a valid Social Security Number (SSN) at the time of the hire will be assigned an interim SSN by the SCO agent per the PIMS manual and SCO agent business process. This requirement tracks a unique number in place of the SSN that identifies the PIMS employee as the PeopleSoft employee for LCD purposes until a valid SSN is updated.	Software Modification	☒ Change to existing Baseline Mod	Release 1
197	WA CSU Job Group	System-wide Human Resources at the Chancellor's Office maintain and manage the CSU Salary Schedule. It is required that the tracking of the FLSA status and the Affirmative Action code is assigned by the Salary Admin Plan/Salary Grade not by Jobcode as delivered by PeopleSoft.	Software Modification	☒ Change to existing Baseline Mod	Release 1
81	WA POI Reports	POI values are in use to track Future Employees, Auxiliary employees, Volunteers, Emeritus, etc. These values allow campuses to have active EmplIDs and facilitate access to campus amenities, training, etc. Campuses have individual processes to report on these. The CO needs to report on Volunteer Faculty across all campuses per agreement with CFA. POI appointments have Business Units, Department affiliations and Expected End Dates and need to be entered, updated, and separated as appropriate. A Data Warehouse solution is needed to enable reporting.	Software Modification	☒ New Mod	Roadmap
83	WA Address Validation	Addresses are a determining factor in benefit plan eligibility. In a system where employees can enter and update their own address, it is important to have a mechanism to ensure that addresses are accurate to ensure accurate benefit plan selection and benefit documents are received by employees. PeopleSoft does not deliver an address validation tool and address validation is not on the Oracle road map.	Software Modification	☒ New Mod	Roadmap
106	WA Restrict Business Phone	PS 9.2 does not deliver the necessary controls on the business phone field to meet CSU standardization requirements or EO 1056.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
147	WA RTP Modification	The delivered functionality does not include the required data elements nor does it track all required data elements in one location to administer the Retention, Tenure,	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap

8.3 Temporary Academic Employment

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
128	TF Workflow	Campuses hire up to 1000s of Temporary Faculty each term. Without implementing workflow within PSFT, campuses will continue manual approvals via paper processing or will seek out or continue using third party solutions. This modification will significantly reduce manual effort system- wide and afford us the opportunity to streamline the approval process with technology efficiencies.	Software Modification	☒ Change to existing Baseline Mod	Release 1
129	TF Appointment Letters	It is a contract requirement that employees in both the R03 and R11 bargaining units receive timely notification of the terms of their appointment and provide positive acceptance. The improvements to the baseline Temp Faculty Module are needed to meet those requirements. Having standard contract templates with concise language and processes will ensure accurate data and may reduce the number of grievances. These modifications allow for better tracking of employee notifications, declined units, concurrent/additional appointments and supports audit requirements.	Software Modification	☒ Change to existing Baseline Mod	Release 1
130	TF Setup - Term and Dept Mapping	Without the modification to the baseline setup table, the temp faculty module cannot be implemented in a consolidated database. Without the requested department mapping setup table, campuses will have to manually track departments that have split, merged, or reorganized, which is laborious and can result in inaccurate data. Additional processes and reports such as WTU accumulation, entitlements, range elevation, lecturer evaluations also will rely on this setup table.	Software Modification	☒ Change to existing Baseline Mod	Release 1
145	TF - Batch Load Updates	Temporary Faculty make up more than 50% of the faculty on campus. Each term campuses hire 1000s of temp faculty. The current Temp Faculty module currently loads large amounts of data to job data, but there are manual cleanup efforts after the load. This modification would auto-populate anniversary codes based on built in logic and allow loading of contract # in the CSU Job table. Also includes adjustments to Run Control to include additional parameters to better prioritize data loads to the system. The goal is a reduction of the number of employment and pay errors.	Software Modification	☒ Change to existing Baseline Mod	Release 1
146	TF - Contract Data Page Updates	The current CSU Temporary Faculty Module allows for only one entry at a time. During any given academic term, campuses process thousands of appointment transactions for academic employees. The gaps identified in the GRP form details the requirements needed for campuses to accurately process employment transactions that affect over 60% of the CSU employees. It's imperative that these transactions are processed accurately for payroll.	Software Modification	☒ Change to existing Baseline Mod	Release 1
169	TF Existing Reports	During SDW Phase I, the Academic Personnel (TF) team identified four (4) current baseline reports that are recommended to be carried forward to CHRS with minor changes.	Software Modification Report or Query	☒ Change to existing Baseline Mod	Release 1

8.3 Benefits Administration

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
85	eBenefits Electric Signature Authorization form signature requirements	The current process of requiring a signature on a paper form for employees prior to the electronic submission of benefits elections creates ongoing challenges for all campuses. California Government Code Section §16.5 allows for digital signature in any written communication with a public entity while explicitly stating it shall have the same force and effect as the use of a manual signature. CHRS provides an opportunity for the use of digital signature within a controlled and standardized environment.	Policy Change		Release 1
102	Benefit Effective Dates	Modification to specific language in the Policy will align with current business practice and vendor plan requirements. Effective dates of plan enrollment are in all cases, the first of the month. The policy refers to deductions and paychecks and payroll calendars do not always coincide with calendar months.	Policy Change		Release 1
45	Dept Security Setup Needs for Benefits	Benefits module does not always provide business unit or company security for the data that is displayed on a page. In a combined environment, all campuses would see every benefit and COBRA event from every campus. This includes employee ID, name, benefit transactions such as termination, divorce or COBRA. The impact of this would be slow page loading (upwards of 30,000 rows), difficulty searching for campus specific employees, and exposure of sensitive transactions (such as termination of campus executive, or dismissals). These impacts can increase during times of large hiring and mass updates.	Software Modification	☒ New Mod	Release 1
46	Benefits Summary	The delivered benefits summary page does not provide a complete picture of historical, current and future enrollment information. Without this information in a single location, the benefits staff must navigate to multiple pages, in up to four locations containing as many as eleven plan types with each area containing historical and future rows (anywhere from 5 to 15) to scroll through before a complete analysis can be made.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Release 1
47	Job Data Summary	The delivered Workforce Job Summary page does not display all employee records (jobs) in a single view. In addition, job data required to analyze, troubleshoot, and audit benefit eligibility is missing from the delivered page. The analysis is required to determine and validate eligibility in various benefit programs related to Health Benefits, Fee Waiver, Retirement, Time Base and Duration Changes, and Bargaining Unit changes. Without this information in a single location, the benefits staff must navigate to multiple pages, employee records, and rows of data before a complete analysis can be made.	Software Modification	☒ Change to existing Baseline Mod	Release 1
53	CSU Pre- Processing	Three configuration fields on job data are used by Benefits Administration to determine eligibility. Specific values are required to be correctly calculated and entered on each job row. While these entries can be made manually, the complexity of establishing the correct values along with the volume of rows being added to job pose a risk of improperly designating eligible or ineligible status. Inaccurate or incomplete information will result in COBOL failure, incorrect eligibility, or invalid or missing benefit enrollments.	Software Modification	☒ Change to existing Baseline Mod	Release 1
67	SCO Benefit Interface	Currently, a CSU interface is generated on a monthly basis to transmit Life, Vision and LTD to the SCO. The SCO Interface process is designed to screen for employees who become eligible/ineligible and adds/cancels their payroll deductions accordingly. PeopleSoft delivers a basic framework to generate flat files from benefits data, however, the requirement to determine which transactions have been submitted, which are waiting to be submitted, and which will need to be resubmitted is not provided.	Software Modification	☒ Change to existing Baseline Mod	Release 1
68	Non Benefit Related Events	Two of the seven benefits codes, MSC and ACT are associated to job changes such as pay, reports to etc.. It is estimated that more than 50% of the MSC and ACT events require analysis by benefits staff. The avg. number of events processed in 2016 for all campuses was approximately 232,200. Eliminating non-benefit related events could improve system processing time, reduce transaction reviews by staff, and reduce the number of events triggered for rework.	Software Modification	☒ New Mod	Release 1
70	PSR Interface	CalPERS is the Health Plan Administrator for the State of California. It is a requirement that all medical, medical cobra and retiree dental enrollment information be provided to the CalPERS system. Additional functions such as clearing errors in calpers, meeting address requirements between PSFT and CalPERS is needed in the CALPERS interface.	Software Modification	☒ Change to existing Baseline Mod	Release 1
71	Delta Dental Interface	At the campus level, the Delta Dental benefits interface streamlines claims processing and reduces the number of inquiries regarding dependent enrollee. PeopleSoft delivers a HIPAA compliant interface process that is currently being used along with modification for specific data elements required by Delta Dental. Specific issues with the existing mod are addressed in this GRP.	Software Modification	☒ Change to existing Baseline Mod	Release 1
74	Permitting Events Codes	The CalPERS PSR interface transmission require CSU specific codes that indicate the benefits permitting event. Without a customization for permitting event codes the interfaces could no longer be used and each campus would be required to manually complete and mail each health enrollment including changes, cancellations, and deletion of dependents.	Software Modification	☒ Change to existing Baseline Mod	Release 1
78	Electronic Benefit Enrollment forms	Current practice is to have employees complete a paper enrollment form, which is then entered into PeopleSoft by a Benefits representative. Asking the employee to complete both online enrollment and a paper form for benefits enrollment is duplicate work and prone to errors or miscommunication causing delays in enrollment or payroll deduction issues.	Software Modification	☒ Change to existing Baseline Mod	Release 1
95	Health Effective Dates	Benefits must always be effective on the 1st of a month and CalPERS requires health enrollments to be effective after the submission of enrollment choices. Benefits eligible employees have up to 60 days, depending on the event, to submit their elections. eBenefits is the recommended path for CHRS, however, PeopleSoft does not provide any configuration for coverage begin dates based upon date of submission.	Software Modification	☒ New Mod	Release 1
105	Benefits Processing Status	The CSU baseline modification that exists for CSUBAS027 and CSUBB010 provides campuses with a report of benefit events by process status. Campuses use these reports to review benefit transactions, troubleshoot issues, resolve enrollment items and perform auditing.	Software Modification	☒ Change to existing Baseline Mod	Release 1
108	Benefits Termination Reports	The current baseline modification, CSUBAS02, is used by campuses to validate the end of coverage due to terminations and job eligibility changes. The process contains 5 separate post processing reports created as a result of job data entry and the Ben Admin Process. These reports help Benefits staff identify employees who have lost benefit eligibility so that staff can ensure benefits are cancelled correctly and timely in addition to providing COBRA notification.	Software Modification	☒ Change to existing Baseline Mod	Release 1
116	Zip Code Upload	CSU Zip Code upload utility is used to update the geographic location table for plan eligibility. Zip codes are obtained from HRM/CalPERS. They can change multiple times a year which affects eligibility. Inaccurate eligibility, delays in enrollments, delivering the incorrect plans to employees are possible issues when zip codes are not kept up to date.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Release 1
117	Retiree Dental Enrollment	Retiree enrollment requires permitting events in the PSR interface. In addition, when enrollment takes place after the retirement date or if there are errors in the interface, the dental form is required to manually enroll and fax it to CalPERS or key the dental enrollment directly into the MyCalPERS system.	Software Modification	☒ Change to existing Baseline Mod	Release 1
52	Dependent Vision Enrollment	Vision coverage is a CSU paid benefit and when eligible, vision enrollment is defaulted and the employee is enrolled in family coverage automatically. To follow the current instructions in a Technical Letter from the CO all dependents enrolled in medical and/or dental coverage must also be enrolled in vision. Currently, campuses must audit enrollment data to determine if dependents are covered and then must manually enroll them.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
82	Confirmatio n Statement	Confirmation statements provide participants with a report of their current elections and dependent information after initial enrollment, qualifying event or open enrollment processing. Campuses are using various methods of providing confirmation to their employees (i.e., printing and providing to employees etc..). The delivered confirmation statements contain multiple pages and requires the printing of hundreds of thousands of pieces of paper (expensive). Employees have stated they find this process wasteful and unprofessional.	Software Modification	☒ New Mod	Roadmap
86	Base Benefits Consistency Audit Report	The Base Benefits Audit Report provides a summary of potential worker data issues as related to Base Benefits business process that enable the Benefits Office to find errors that would otherwise show up when attempting to process enrollments or changes. As delivered the Base Benefit Consistency Audit Report contains a number of entries which are not useful to Benefits staff and cause the report to be extremely lengthy, making it burdensome to review/audit.	Software Modification	☒ New Mod	Roadmap
96	BA-Uploading Documents	Benefit enrollments covering dependents require supporting documentation to verify the relationship and responsibility for health coverage. CSU needs an online submission process to provide a single location for any and all benefits documentation in order to facilitate compliance, protect private information and provide flexible access.	Software Modification	☒ New Mod	Roadmap
101	BA-COBRA Letters	COBRA notifications are required by Federal and State Legislation. COBRA notifications are r equi r ed to be sent within 14 days of the COBRA qualifying event. Failure to comply in a timely and accurate manner could create legal and financial liabilities. Campuses generate COBRA letters in a variety of manual processes. San Diego is the only campus using the PeopleSoft COBRA module (with a modification) to generate	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
120	Manage Event Flags	The delivered flag report (BAS008) is used to identify events that have had job, address, or union eligibility information changed, events that have been processed out of sequence, and events that have been disconnected during processing. Every campus must run the delivered flag report, and review each flag to determine its applicability to benefits enrollment, status and eligibility. Currently, there are over 579,000 flags that will require staff review. It is estimated that over 50% of those have no relevance to eligibility or enrollment and take resources away from other benefit tasks.	Software Modification	☒ New Mod	Roadmap
121	Void Disconnected Events	Voiding disconnected benefit events is important for any event that may have changed employee benefits. The purpose of the Void process is to remove any rows from the base benefit tables that were created by the event. In the case of a finalized termination event that inserted termination rows into base benefit tables, the disconnected event must be voided to remove the termination of benefits.	Software Modification	☒ New Mod	Roadmap
158	Fee Waiver Request and Tracking	22 Campuses and the Chancellor's Office manually track Fee Waiver requests using paper forms and excel spreadsheets. Northridge has been using their online modification for three years enabling them to successfully manage fee waiver electronically. CHRS is our opportunity to provide an automated process and tracking capability of Fee Waiver, maintaining a fiscally responsible program.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
165	GRP-BA Notes and Tracking	Currently campuses have developed a variety of methods outside PeopleSoft to meet the need of noting information related to an Employee or Dependent record or for tracking event specific confirmations of enrollment required to ensure employee benefits are administered at various vendor sites (CalPERS, SCO, Delta Dental). Reconciliation against vendor systems is required. When enrollment errors occur, the results are too often significant Benefits Analyst time to correct the problem, accounts receivables for employees (involvement by Payroll), employee stress, loss of employee trust, grievances etc.	Software Modification	☒ New Mod	Roadmap
185	Self-Service Leave Donation	Leave donation is processed manually at all campuses, it crosses multiple departments and directly impacts employee sick and vacation balances. The delivered leave donation module meets all of the requirements for a CSU program in a single campus environment, however, this modification is requested to meet the needs of the multi campus environment for CHRS.	Software Modification	☒ New Mod	Roadmap
188	Extended Leave Notification Letters	Department of Labor requires legal notifications to employees regarding eligibility for leave and their rights under the Family Medical Leave Act. Currently there is no standard letter template that recommends content, verbiage or format. A common approach with PeopleSoft templates in BI Publisher would provide consistency in employee notifications.	Software Modification	☒ New Mod	Roadmap
189	Dept Tree Security - Administer Extended Leave	Use of the delivered module for Extended Leave will provide all campus leave coordinators access to all leave information for every campus. The administrative page should be secured in compliance with CSU IT Security policy regarding private information. In addition, it is expected that performance issues may be encountered with a large volume of data populating on the page.	Software Modification	☒ New Mod	Roadmap

8.5 Time and Labor

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
92	Wet Signature Policy	There are varying practices amongst the campuses. Clarification is needed to know how to proceed with the paper form retention recommendations (if they are needed or not).	Policy Change		Release 1
173	TLAM Uniform Pay Day Policy	HR/Salary 2011-01 required that each campus establishes a single pay schedule, which includes same pay periods and pay days, for all positive paid employees and student employees (both represented and non-represented). Campus pay days currently range from the tenth of the month to the fifteenth. Campuses run time admin at their respective campuses and send separate PIP files to the SCO for their student employees and positive paid employees. This will not work in a consolidated environment. Common pay cycle schedules by pay period need to be established and communicated	Policy Change		Release 1

8.6 Absence Management

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
174	TLAM ADO Units Policy	Tech Letter HR/Salary 2013-15 was released on April 23, 2013 regarding the accrual of an Alternate Day Off (ADO). It clarified for CSUEU that ADO was to be tracked in a unit of 1 so that employees would not have to use additional leave credits to make up the difference. This did not clarify for other bargaining units, nor did all campuses move to this configuration or format. Some continue to accrue at a rate of hours rather than a unit of 1.	Policy Change		Release 1
93	Dock Policy Clarifications	There is a dock procedure in place but no rules surrounding how/when dock can be utilized. The practice for when to allow an individual to utilize the dock varies from campus to campus.	Policy Change		Does not support
133	TLAM - Need policy on no leave taken	Currently, there is no clear policy on how the no leave taken tracking is applied to employee groups. The current policy leaves interpretation up to the campus, resulting in disparate practices when it comes to faculty. These practices can only be reconciled through a clarification of policy. Specifically, we would like to either the no-leave-taken to be required by all employee groups or none of them.	Policy Change		Does not suppor t
134	TLAM - Standardize Excess Minus Reconciliation Policy	All Campuses must complete the year end reconciliation of excess/minus hours, a process that involves several steps involving the employee, the system, the payroll office. In order to automate the process, a standard cascading order must be defined by policy (e.g. ADO, HC, CTO, PH, Vac) and be agreed upon by all affected parties.	Policy Change		Deny/ Roadmap
135	TLAM - Policy clarification on the use of Professional Development Leave	While the Technical Letter TL-LVS2014-02 Professional Development Time gives definitions and uses managers and campuses interpret these uses in different ways. Use of this leave type is entered for training, when utilizing the fee waiver program, classes, when attending conferences…etc. The Fee Waiver policy does not specifically call out the usage of PDL. There are, however, campuses currently using PDL for Fee Waiver classes.	Policy Change		Does not support
151	TLAM Balance Inquiry	In the current 9.0 system, there exists a detailed balance inquiry page with historical and current data on an employees’ accruals, takes and adjustments. There exists a view absence balances page as part of the delivered 9.2 employee and manager self-service, but this page does not include any detail regarding takes, accruals, or adjustments; current or historical. The terminology used by the delivered page is not user friendly.	Software Modification	☒ Change to existing Baseline Mod	Release 1
152	TLAM Comments in Absence Adjustments Notepad	In the current 9.0 environment, the absence adjustment page has been modified to include a link to the HR notepad. This is heavily utilized to track the comments regarding adjustments to absence balances. The HR Notepad is delivered, but there is no direct access to it from the adjustments page. There is no delivered solution to record comments within the balance adjustments page.	Software Modification	☒ Change to existing Baseline Mod	Release 1
179	TLAM - Forecasting Modification to Enhance Accuracy	The Forecasting function was not activated (turned on) in 9.0. When trying to identify available balances in order to pre schedule absences (i.e. vacation) , current balances must manually be reviewed and then be manually calculated out to determine if balances will be available to the employee. The recommendation is to utilize the forecasting tool in 9.2 to streamline this process.	Software Modification	☒ New Mod	Release 1
186	TLAM - Absence Multi-Reports	In the current 9.0 baseline environment, CMS provides and supports a series of reports to facilitate absence process. Campuses have come to depend on the absence multi-reports in order to streamline day-to-day operations as well as respond to use inquiries. Most of these reports have existing errors that have been slated to be fixed as part of CHRS. Campuses would struggle if the reports	Software Modification Report or Query	☒ Change to existing Baseline Mod	Release 1
191	TLAM - Projected Vacation Payout Report	There does not exist a standard way of estimating payouts within a department, however, this is an important part of determining a department's budget. Chico has developed a report which other campuses find useful and request to be included in CHRS.	Software Modification Report or Query	☒ Bring forward existing campus mod (tech specs required)	Release 1
150	TLAM AM Retro Trigger for Timesheet Updates	When timesheet data is reported for the current pay cycle, those transactions are processed by AM by running the AM process using the “Recalculate All” option. When timesheet updates occur for prior periods, it requires staff in Payroll/HR to review and manually calculate the impact to absence data. This process is labor intensive and prone to human error. This process could be easily captured and recalculated as part of absence’s retroactive processing procedure.	Software Modification	☒ New Mod	Roadmap
171	TLAM - Absence Management Auto- Enrollment	Employees who are absence eligible must be enrolled in the appropriate Absence System, Absence Pay Group, and Eligibility Group. Currently, enrollments to employee records are manually entered in JOB data. The staff member performing the updates in Job Data must review the employees’ union, job code, FLSA status, employee class, and employee type to determine if the employee is eligible for absence and then enroll or update the correct Absence System, Absence Pay Group, and Eligibility Group. This process is cumbersome and very time consuming.	Software Modification	☒ Bring forward existing campus mod (tech specs required)	Roadmap
190	TLAM - CHRS Reports from SLO SQRs	In a consolidated environment, reports and audits must be made available for campuses to perform ongoing monitoring of the system. Several existing SLO reports have been identified by the leads as useful in a consolidated environment and requested to be brought forward.	Software Modification Report or Query	☒ Bring forward existing campus mod (tech specs required)	Roadmap
194	TLAM - Employee Data Transfer Report	When an employee transfers from a state agency or another campus to a CSU campus, a 612 form is manually completed. The current process is manual and entails having a piece of paper with sensitive information such as SSN, benefits, and leave information transferred from one person to another for review. Since all of the data required to complete the form will already be in the CHRS system, we propose eliminating the paper process and replacing it with an electronic one to improve security and efficiency.	Software Modification Report or Query	Transactional Report/Query	Roadmap

8.7 LCD

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
87	LCD Multi Campus Processing	Currently, each campus receives a Pay tape from the State Controller’s Office (SCO). Each campus then completes the LCD processes. In a consolidated database there must be a method to distinguish each campus so that each campus only processes their own LCD data. There are no plans to centralize Payroll nor LCD processing for all campuses. Additionally, if this were to be centralized, the need to distinguish each campuses data will still be needed.	Software Modification	☒ Change to existing Baseline Mod	Release 1
97	LCD_ FTE Calculation in LCD	The delivered PeopleSoft field ‘FTE’ is used to store the calculated FTE value. In LCD, the value is calculated as an absolute value (meaning it can never be negative), because the delivered PeopleSoft field FTE is not designed to handle negative values. Therefore, even in cases where the calculated FTE value would be negative, LCD stores it as a positive value causing FTE to always be overstated for any negative amounts and causes inaccuracy in the data.	Software Modification	☒ Change to existing Baseline Mod	Release 1
107	LCD_Eliminating Unused Objects	During the CHRS review of LCD processes it was determined that there are several LCD objects (pages, records, programs, processes, etc.) that are no longer being used by campuses. Eliminating unused LCD modifications will make it easier to implement Commitment Accounting in the future.	Software Modification	☒ Change to existing Baseline Mod	Release 1
110	LCD_Expenditure Transfer By Employee - Add Preliminary Test Feature	Campuses currently do an Expenditure Adjustment by Employee when the funding source of the position has to be changed after charges have been processed by LCD for previous pay periods. Users correct any mistakes made via the Expenditure Adjustment Correction page. this page is complex and requires the user to create every expense line related to the adjustment (can be 16 lines per person) This modification will allow the user to preview the expenditure adjustment changes before they are committed to the system	Software Modification	☒ Change to existing Baseline Mod	Release 1
111	LCD_Exp Adjust by Employee Multiple Charge Periods	When campuses have to create individual Expenditure Adjustments by Employee for multiple charge periods, the user has to create a separate Expenditure Adjustment for each charge periods because the process is designed to only handle one charge period at a time. On average campuses have between 100 – 200 adjustments by employee per fiscal year, creating separate adjustments for each charge period is very time consuming. During fiscal year end there could be a high volume of funding changes that need to be completed, via this process, in a timely manner to adhere to year end close deadlines.	Software Modification	☒ Change to existing Baseline Mod	Release 1
160	LCD_Eliminate CSU Budget Adjustment Page	The CSU Budget Adjustment Page is a custom CSU page, currently only one campus utilizes this page. Eliminating the page will remove a custom page from a PeopleSoft delivered component, this will streamline upgrades and will be aligned with any future implementation of Commitment Accounting.	Software Modification	☒ Change to existing Baseline Mod	Release 1
109	LCD_GL Interface CSULCD50 New Audit Report	When campuses run the CSU GL Interface (CSULCD50) program if an error occurs the program stops and the error must be corrected. The correction can require backing out multiple processes requiring additional time and effort. Once the error is corrected and the program restarted, an additional error could be generated. This requires going through the same correction process as previously noted. When errors are found in this program, there is generally more than one error therefore resolving the errors is very time consuming.	Software Modification Report or Query	☒ New Mod	Roadmap
112	LCD_Expenditure Adjust by Employee Zero Check Processing	The SCO Pay tape may contain Reversals and Redeposits. The reversal and r e d e p o s i t will have check number of zero. If an Expenditure Adjustment is needed for any of these, the program does not process any zero numbered checks.	Software Modification	☒ Change to existing Baseline Mod	Roadmap
113	LCD_Combo Code Build Preliminary Test Feature	Currently when new chart field strings are created campuses need to run the CSU Combo Code Build. This data generated from this process includes the SetID, DeptID, and Fund values etc. The program currently does not have a preview feature, if typos or mistakes are entered the combo codes are generated and cannot be eliminated. Having inaccurate data creates performance issues in the database and creates data integrity issues. This impacts the LCD module as well as the Time and Labor module (Create Additional Pay page).	Software Modification	☒ Change to existing Baseline Mod	Roadmap
122	LCD_CSU Distribution Errors Correction Page	Currently, all errors listed must be corrected before page can be saved. Need method for campuses to be able to save work completed. Generally, when errors generate there could be up to 16 entries that need to be corrected per employee, this displays earnings, deductions, and taxes. For example, if there are a large number of employee errors the amount of errors to correct would be multiplied by 16. Additionally, there could be errors for multiple charge periods. The system can time out before all errors have been addressed, the user will then have to start all over again.	Software Modification	☒ Change to existing Baseline Mod	Roadmap

Recruiting

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
CHRS 1024	Integrat ions	CHRS Recruiting has created integration processes for both Outbound and Inbound. Outbound load Users, Hierarchy Tree, Teams and other information needed from PS to load into PageUp. Inbound integrates candidates that have accepted a job offer into PS job. This development was created into 9.0 and needs to be retrofitted into the 9.2 environment	Software Modification	☒ Change Control	Release 1

8.9 Security

GRP ID	GRP Title	Summarized Business Need	GRP Type	Modification Type	Release
124	CSU Security Reports	We are requesting access to specific reports the CSU is currently providing for us for Segregation of Duties and security auditing purposes. PSFT 9.2 does not deliver this functionality and it does not appear to be on Oracle’s roadmap/future Oracle release.	Software Modification	☒ Change to existing Baseline Mod	Release 1
125	User Profile Security	This modification will impact CMS and the campuses. It limits the DSA from access to other campus DSA accounts other than their own campus DSA accounts.	Software Modification	☒ Change to existing Baseline Mod	Release 1
126	Disable Sign-On Screen After User Signs Out	In an effort to protect our Personal Identifiable Information, the CSU is required by Federal and State Local Regulations as well as CSU Policies and Standards to safeguard our sensitive data. After users are finished with a PeopleSoft session, they click the “Sign out” hyperlink and are back on a sign in page. To secure the CHRS production instance, the browser tab should close after users click the “Sign out” hyperlink. This is currently implemented in CFS production instance. This will assist in the prevention of unauthorized user attempts in guessing a user's login credentials.	Software Modification	☒ Change to existing Baseline Mod	Release 1
138	Secure Record to Paycheck Table	In an effort to protect our Personal Identifiable Information, the CSU is required by Federal and State Local Regulations as well as CSU Policies and Standards to safeguard our sensitive data. Without this in place, it increases the risk to the CSU in the event of a security breach, resulting in financial losses. A review of all secure records was conducted by the Security Leads and a decision was made to secure this particular record due to the highly sensitive data that it contains. This will limit the user to view authorized records.	Software Modification	☒ New Mod	Release 1
141	Create Views for Tables with Sensitive Data	In an effort to protect our Personal Identifiable Information, the CSU is required by Federal and State Local Regulations as well as CSU Policies and Standards to safeguard our sensitive data. Without this in place, it increases the risk to the CSU in the event of a security breach, resulting in financial losses. Users will be able to retrieve information from the system by using one table as opposed to many and the information is readily shared. Saves time and reduces complications within the queries. Ensures that sensitive data is secured and reduces overall risk to the CSU. Makes reporting easier.	Software Modification	☒ New Mod	Release 1
175	Single Sign On	The Common Human Resources System (CHRS) is to be shared with all CSU campuses and therefore requires a login methodology that would not require extensive central support thereby necessitating additional staff. A single sign-on methodology was approved and this modification was required for this functionality. The campus CHRS users will sign in through the CSU portal using single sign-on.	Software Modification	☒ New Mod	Release 1
195	CMS Tech Mod - Tracing Console	The implementation of new security practices has led to an increase in complexity for certain technical support functions, namely, the ability to do pin-point tracing, view trace results online and easily delete those trace files online without the need for technical staff involvement.	Software Modification	☒ Change to existing Baseline Mod	Release 1
198	CMS Tech Mod - Post- Clone Security Scripts	CMS requires campus clones in order to conduct enhancement testing and to research production issues. Access to these clones is often time-sensitive. If user profiles, roles and permission lists have to be re-created manually every time a campus clone is created, access to each clone will be delayed by almost a week. Or multiple CMS staff would need to be utilized to achieve a reasonable turnaround time.	Software Modification	☒ Change to existing Baseline Mod	Release 1
199	CMS Tech Mod - FTP	FTP Utility is an integrated tool for end users, mainly CMS BSAs. Benefits uses this tool to upload zip code and rate data; Workforce Admin uses this tool for salary schedule load and pay tape load; and all modules use this utility for the general purpose of uploading data in testing.	Software Modification	☒ Change to existing Baseline Mod	Release 1
201	CMS Tech Mod - IB PubSub Start Stop	The existing baseline modification would support improved performance and data management in a consolidated multi-campus HR environment. By eliminating manual steps and the need to access HCM this modification reduces manual effort and adheres to security protocols.	Software Modification	☒ Change to existing Baseline Mod	Release 1
207	CMS Tech Mod - CSU Setup	This modification provides CSU and campus specific setup information in general pages as part of configuration. Multiple modules use the setup data within their module, for interfaces, and other CSU specific modifications. It provides a central location to store and manage general configuration items.	Software Modification	☒ Change to existing Baseline Mod	Release 1

9.0 Appendix B: Change Control Requests * as of last revision

9.1 Workforce Administration

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1023	For data coming from PageUp with student data, there is a need for the ability to pull data from the PageUp staging table and validate against the same Hire eligibility requirements		Release 1
CHRS 1033	This mod needs to be amended to use the Empl record crosswalk table	142, 163	Release 1
CHRS 1082	Enhance the WA Student Hire mod to include additional checks	69	Release 1
CHRS 1122	Requested updates from Task Force to existing development	157	Release 1
CHRS 1123	Requested changes to workflow from the TFE Taskforce	157	Release 1
CHRS 1148	To allow for future new hires to appear in both Job and Query.		Release 1
CHRS 1167	Self Service - Address Line 2 E95and 3		Release 1
CHRS 1216	HR 9.0 COVID Modification		Release 1
CHRS 1217	Rehired Annuitants		Release 1
CHRS 1257	Please move "CSU Dept Roll" Process to be under HCM SetUp		Release 1
CHRS 1318	Allow ITIN for POI type		Release 1

9.2 Benefits Administration

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1008	This request is for 4 additional Electronic Benefit Enrollment forms 1) Events Summary Report, 2) Affidavit of Parent- Child Relationship form, 3) Domestic Partner Dependent Certification form and 4) Dependent Verification Affidavit form.	78	Release 1
CHRS 1028	Additional requirements were identified during the writing of the Design Spec (1. Import Delta Dental Error Report and 2. Import Delta Activity Reports).	71	Release 1
CHRS 1046	PSR Interface change is needed to allow retiree dental enrollment in either of two enhanced dental plans for non-FERP retirees and send new plan codes this logic.	70	Release 1
CHRS 1055	A modification to CHRS that allows the PSR interface to cancel health enrollment coverage for non-CalPERS members who lose coverage due to separation.	70, 117	Release 1
CHRS 1063	GRP 68 Evaluate for Eligibility	68	Release 1
CHRS 1067	Conversion - Benefits		Release 1
CHRS 1081	Create Database-Level Audit Tables for Ben Admin and Base Benefits		Release 1
CHRS 1083	Add custom text on the Dependent and Beneficiary Coverage Summary page		Release 1
CHRS 1094	GRP 68 Requires Redesign to provide successful results for Benefits Employee Self Service processing	68	Release 1
CHRS 1287	Add missing Benefits tables for conversion.		Release 1

9.3 Time & Labor

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1032	This mod needs to be amended to use the Empl record crosswalk table	73, 182	Release 1
CHRS 1039	New Report - REQUEST: Create a report/process to allow campus users to monitor their student employees' actual workload.		Release 1

9.5 Absence Management

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1011	Transaction Routing	219	Release 1
CHRS 1053	Provide a mechanism for employees and managers to be notified of vacation balances that are expected to be over the annual maximum. Bargaining		Release 1
CHRS 1292	v 9.2 - AM: Schedule Conversion Issues - 01/2022		Release 1
CHRS 1296	Request to create a role to grant readonly access to Absence Event Entry tab and also remove access to Forecast Messages tab		Release 1

9.6 Labor, Cost and Distribution

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1062	These mod needs to be amended to use the Empl record crosswalk table	87, 97	Release 1
CHRS 1066	GRP 111 was created for LCD to handle Multiple Charge Periods for the Expenditure Adjustments by Employee. It was determined that this approach would work for campuses that have mapped all their earnings to the same account number. However, for campuses that have mapped different account numbers for different types of earning (e.g., regular earnings, stipends, overtime, bonuses, …), a different approach to the Expenditure Adjustments by Employee for Multiple Charge Periods is required.	111	Release 1

9.7 Recruiting

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1024	The CHRS Recruiting integration needs to be retrofit into the 9.2 environment	223	Release 1
CHRS 1180	POI creation - Add Security Access by Department Level		Release 1
CHRS 1183	Job History Link		Release 1
CHRS 1184	Job Tab		Release 1
CHRS 1185	Absence Management field		Release 1
CHRS 1189	Process Indicator		Release 1
CHRS 1191	Add From/To Date range in Data Import page		Release 1
CHRS 1192	Staging table data display		Release 1
CHRS 1193	Student Hire Processing taking defaults from CSU Student Hire setup tables		Release 1
CHRS 1194	Faculty Fraction fields showing decimals		Release 1
CHRS 1195	Disability field not displaying property		Release 1
CHRS 1196	Profile - license verified checkbox		Release 1
CHRS 1197	Process Status Tab - Last Updated by field		Release 1
CHRS 1198	Expend field width to display full value		Release 1
CHRS 1199	Simplify Search Match Result labels		Release 1
CHRS 1200	Anni Month field auto rule		Release 1
CHRS 1201	App Engine Process Error Message		Release 1
CHRS 1204	Error Page to add filter for ease of search		Release 1
CHRS 1205	Add additional field on error log page to distinguish same employee different transactions		Release 1
CHRS 1208	Error log - error message missing employee data		Release 1
CHRS 1209	Add License verified checkbox when loading profile if a license exists		Release 1
CHRS 1243	CHRS Recruiting Integration - allow reporting against error table, staging table and emplID-userID-applicantID mapping table within PeopleSoft		Release 1
CHRS 1286	CHRS Recruiting-Preferred Name Change Report: Add a field on the report to show what the previous name was for the employee, Add job code for employees primary job only		Release 1
CHRS 1338	Revision to Job History display page to include business unit		Release 1

9.8 Security

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1015	Additional Security GRPs to De-commission Roles That Were Manually Added	210	Release 1
CHRS 1017	Operator ID Provision	212	Release 1
CHRS 1051	Deliver POI Security in CHRS		Release 1
CHRS 1073	Query View		Release 1
CHRS 1146	To have the POI Department Value 2 (Department) field look at the HR Department Security tree and not just the department table
CHRS 1267	Primary Job: The Primary Job is nested in a PSJob and on the Process Monitor it is called PRJJOBIND. See screen shot below. Requesting the ability to see the log that runs nightly for primary job, by changing the distribute to a role and with log selected to be delivered to Report Manager.

9.9 Temporary Academic Employment

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1258	All Business Units are not available in the list/table of campuses.	129	Release 1
CHRS 1290	Data Entry Page and Approvals Page – Logic on Saving and Submitting		Release 1
CHRS 1291	Create process to move TAE configuration from one pass to another and to MTP		Release 1
CHRS 1303	TAE Appt Data Entry Page - Warning Message for Salary Needed		Release 1
CHRS 1354	Use of DTA/CNR is Unclear on CSU TAE Appt Data Entry Page		Release 1
CHRS 1378	Add Base Salary and Hourly Rate Validation to TAE		Release 1
CHRS 1379	TAE Appointment Data History Table is Required to Meet CSU Record Retention Policy		Release 1

9.10 Miscellaneous

CC ID	Summarized Business Need	GRP # (if applicable)	Request State
CHRS 1022	This modification is required to maintain the current approvals flexibility in both absence management and time & labor.	221	Release 1
CHRS 1277	Conversion made a change to position in V9 to turned on flag for "Includes Sal Plan grade" checkbox (POSITION_DATA.INCLUDE_SALPLN_FLG.) which is causing downstream issues where programs no longer work.		Release 1

End of Article

0 Comments

Add your comment

Previous Article (job aid) Query Policy Guide

Next Article (job aid) CHRS Roadmap