In the current CMS environment, all personal data is shared between HR and CS for each campus. Any person entering either system is automatically synched between the two. Campuses currently have no way of knowing if a person exists at another campus. In CHRS this will no longer be the case because it is a shared environment. CHRS employees/POIs have their personal data in Campus Solutions but those who are only students will no longer have personal data or exist in CHRS. CS has a mapping table that connects the CS and CHRS IDs because the Employee ID will no longer be the same in each system.

CHRS functionality requires limited information from the CS system. Database links will be used by CHRS to retrieve the data from CS. This means that CHRS will require 23 database links, one for each campus separated by business unit. These exceptions are detailed below.

1. Student Hire
   • Uses database links to perform the necessary validations in Campus Solutions. The module confirms that a student is currently enrolled in classes to work for that semester. If they are not enrolled, a warning message is generated. For work study, if a student is being hired or is already employed in that job code, the module confirms that the student has an award for the current term. Along with confirming the award minus disbursed amount is greater than zero.
2. Time and Labor Student Processing
   • Contains validations to ensure students are eligible to report time and not go over their Work Study amounts. The module used database links to perform these edits.
3. Temporary Academic Employment (TAE)
   • Uses database links to access the necessary data in Campus Solutions for the Course Assignments tab under the Appointment Notice Tile in Employee Self Service.
   • Uses database links to access the necessary data in Campus Solutions for the employees term workload under the "Empl Stat" value located on the CSU TAE Appointment Data Entry and CSU TAE My Approval pages.
4. CHRS Crosswalk Table
   • The CHRS Crosswalk table is housed on the Campus Solutions side.
   • Campus must allow the mapping table to be built if they want the views from CS to CHRS to work.
   • Campus Solutions delivers this mapping table that links the CHRS ID to the Campus Solutions Employee ID. The CHRS process is going to change the Employee ID of employees in the HR system. This will necessitate some mapping tables to link a person with different ID’s. The following are the list of mapping tables that have been identified:
     • Historical HR Data – All historical data is not going to be converted into CHRS.
       • Each campus will have its own repository of historical information. Because the Employee ID is going to be changed in CHRS a mapping between the old Employee ID and new CHRS ID is necessary.
       • Employee Record Number Mapping (CSU_JOBEMPL_MAP) – Employee Record numbers may need to change when employees are converted. CHRS conversion will create a mapping table that will map the old Employee Record Number to the New Record number for the CHRS ID. Processes such as PIP and the PPT which use the Employee Record number will need to use this mapping. In CS, the Employee Record will be converted at the time of CHRS implementation.
     • CS to CHRS ID - The Campus Solutions system has views into the Job Data of the employees in HR. This view will need to be able to map the CS Employee ID to the CHRS ID. A cross reference table will be maintained in the CS database that will contain the mapping (CSU_CHRS_XREF). Only the Employees for that campus will be included in each campus’s system. This will allow the views to join to the mapping to ensure a campus cannot see Job data from another campus. Because people can have jobs in multiple campuses, Business Unit was added into the baseline views to restrict the jobs that can be viewed.
       • Campus Solution Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
     • CHRS ID to CS ID from PSOPRDEFN- In CHRS, the CSU_EMPL_MAP_VW is updated when a new employee or POI is created in CHRS, is sent to CS, and CS returns an entry to PSOPRDEFN which includes CS EMPLID. In the table “EMPLID” refers to CHRS ID and “OPRID” refers to the two digit campus code +9 digit CS EMPLID.
       • CHRS Navigation: Menu > PeopleTools > Security > User Profiles > User Profiles

1. CHRS Security- User Profile
   • CHRS will use the CS ID to create a User ID. This ID will not exist when an employee is created. Once the employee is created in CHRS a message will be sent to Campus Solutions to also create the person. The crosswalk table will be populated to show the relationship between the CHRS ID and the CS ID. In doing so Campus Solutions will know that a User ID will need to be provisioned in CHRS. CS will send a message to the CHRS system so the User ID can be created. The message will contain the following fields:
     • CHRS ID
     • Campus Solutions ID
     • Campus Code
   • When the User Profile is created in CHRS, a User Profile is NOT created in CS. Campuses must create a provisioning process if they want a User Profile created in CS.
2. Business Phone
   • Personal Data updated in CS will not be sent back to CHRS, including the Business Phone. However, if the Business Phone number is updated in CHRS, it will be sent back to CS.
3. Business Email
   • Personal Data that is updated in CS will not be sent back to CHRS. The exception to this is the business email. CS business email will be sent to the User Profile (PSOPRDEFN) in CHRS under the field EMAILID. In CS the business email must be added/updated using the Add/Update a Person component and not the Electronic Addresses component.
     • Campus Solution Navigations: Menu > Campus Community > Personal Information > Add/Update a Person
     • CHRS Navigations: Menu > PeopleTools > Security > User Profiles > User Profiles
   • For CHRS if the EMAILID is updated in PSOPRDEFN, it will not be sent to CS.
   • Campuses will need to modify their provisioning process in CS, if they want the Business Email to flow to CHRS. 

Both CHRS and CS have different ways of searching for a person. 

1. CHRS
   • CSUID Search – Searches all employees and POIs in the CHRS database.
   • Student Hire – Searches all students at the campus using Database Links.
2. Campus Solutions
   • CSUID Search – Searches all persons in the CS database.

A single database link contains multiple tables/views that CS, CHRS, and CFS use to pull data. These tables/views have been standardized, simplified, and approved by the Chancellors Office. With CHRS being a shared environment, some of the tables/views have been modified to remove Level 1 Data (SSN, Citizenship, DOB, etc.). Many of the views are locked down in CS using a crosswalk table that uses Business Unit or Company. There will be 23 database links pulling CS data into CHRS (I.e., for TAE, Student Hire). The naming convention is CSU_<3 digit company>CS * per development environment views; this may change. Campuses should review all areas where database links are used and determine retrofits.

For more information review the DB Link Details and Integration FAQ documents located in the CHRS Knowledge Base.  

CHRS does not convert all historical data from campuses. The data will be kept in a repository available only to the campus. If a campus needs data from the historical repository, they will need to create reports that access this data. A crosswalk table will be created at the time of conversion to link the new CHRS ID to the old campus HR Employee ID. There is a mapping table in CHRS that links CHRS emplID to the emplID in 9.0 and will match the records for each employee (CSU_EMPLIDMAP, CSU_JOBEMPL_MAP). These tables are created at time of conversion and are not maintained going forward.

1. CHRS Integrations List

• The following are the list of interfaces identified by CHRS. Details regarding each interface can be located within various CHRS Design Specs.
  • GRP 68 SCO Benefit Interface
  • GRP 70 PSR Interface
  • GRP 71 Delta Dental Interface
  • GRP 87 LCD Multi Campus Processing
  • GRP 97 FTE Calculation in LCD
  • GRP 146 Contract Data Page Updates
  • GRP 73 CSU Payroll Input Process – PIP
  • GRP 156 Salary Schedule Load
  • GRP 159 Hourly Student Employee Hiring Process
  • GRP 69 Student Employment
  • GRP 142 PPT Mod
  • GRP 163 SSI GSI Prob to Perm
  • GRP 212 Create the CHRS Operator ID CSUCO ITS 

2. Identity Management Views 

• In the current CMS environment several views have been created that are accessed by the Identity Management system outside of the PeopleSoft framework. The views are accessed at the Oracle level. These views need to be maintained. These views will need the CHRS ID as well as the CS ID. A crosswalk table will already be available in CS. In addition, a DB link to all the necessary tables will be included in CS. These views should be moved to be run from the CS environment. Below is a list of the Identity Management views that need to be moved to CS.
  • CSU_IAM_CATEGRY
  • CSU_IAM_EMAIL
  • CSU_IAM_EXEC
  • CSU_IAM_FACULTY
  • CSU_IAM_STAFF
  • CSU_IAM_STAFMPP
  • CSU_IAM_STATE

3. Common Solutions

• The interfaces already identified by CHRS are examples of Common Solutions interfaces. These interfaces all work with the same third-party system for each campus and therefore can be standard. When campuses define their interface needs if the same interface is identified to the same third-party system, it can be defined as a common solution interface.

4. Common Door

• A common door interface is defined as the same data going to or from CHRS from different systems. Campuses use different systems to collect the data, but the data could be batched and sent to CHRS in the exact same format. A “common door” interface requires the third-party system to format input data or accept output data in the exact same format regardless of what third party software is being used.
• Currently there are no examples of Common Door interface.
• Campus with identified needs for Common Door should submit a CHRS Change Request

Campus specific interfaces if approved will be entirely built and supported by the campus that has the requirement. The interface will not allow you to use any objects that are included with CHRS; everything must be custom. No data will be coming into CHRS from external sources.

CFS and CS will maintain the same IDs, which is equivalent to the campus code prepended to the CS EmplID.

1. Chart Account Data
   • The chart of accounts includes account numbers, departments, and other chart fields. These items are created in CFS and currently there is an integration to move these values across to the appropriate HR instance. This integration has been modified by CHRS to use a campus identifier to distinguish between campus values as all integrations will flow between CFS and CHRS.
2. ESP
   • The Employee Salary Projection creates an output file for the FIRMS system.
3. Labor Cost Distribution
   • The Labor Cost Distribution process is a series of programs that takes a feed from the PIMS payroll system at the State Controller’s Office (SCO) and creates financial journal entries from the payroll data. Currently a separate file is created for each campus to load into their HR instance. Each campus independently uses an integration to load the CFS Finance database with the journal entries. CHRS has modified this process to allow each campus to run its LCD process independently. Integration will be by business unit from CHRS to CFS. Even though it is the same integration process each campus will run it independently.
4. Concur
   • Concur is a third-party travel reporting system that relies on downloads from CHRS to build an active employee directory that are eligible to enter travel expenses. The integration pulls all active employees from the PS_EMPLOYEES table which is refreshed nightly from the CHRS job PER099 (this is a scheduled job but can be run nightly for test instances: Set Up HCM > System Administration > Refresh Employees Table). In CHRS, when new employees are added, deleted, or change “reports to”, this triggers updates to Concur. Note, direct updates to Concur can also take place.

In HR 9.0, campuses were responsible for monitoring and resolving integration errors. When errors were unclear or difficult to resolve, campuses would open ServiceNow tickets to work with CMS to resolve. In CHRS, campuses do not have access or responsibility to monitor Synchronous or Asynchronous Integration messages. For CHRS, Synchronous and Asynchronous Integration messages are monitored by the CMS team through Nagios.

Nagios reviews CHRS hourly by looking back at both Synchronous and Asynchronous Integration messages for errors that occurred within the last 60 minutes. When Nagios locates an integration error an alert is generated and a ServiceNow ticket is created and assigned to CMS-CHRS. When the CMS-CHRS team receives the ticket, the campus will be notified that research regarding the error is being conducted. Once additional information is collected, the ServiceNow ticket will be updated if the error has been resolved or additional information to guide the campus for further review.

Integration archiving and purging is done for performance and general maintenance. It’s recommended to archive older messages to clear space on the live messaging tables. In HR 9.0, campuses were responsible for setting up and maintaining the archiving and purging of integration message. Campuses often set up their Campus Solutions database to have the same criteria to allow for easier integration troubleshooting. With CHRS, a standard was created for archiving and purging both Synchronous and Asynchronous Integration messages in CHRS. In CHRS, purging of Synchronous and Asynchronous Integration messages only occurs during an upgrade. Whereas archiving occurs automatically for Synchronous and Asynchronous Integration messages that are older than 60 days in a “Done” or “Cancel” status.

Campuses are not required to alter their Campus Solutions database to match the archiving and purging integration messages standard in CHRS. However, campuses should confirm that their current process maintains messages longer than 2 days, to allow for adequate troubleshooting.