All HR 9.0 and current CHRS campuses are using Integration Model 1. Under Integration Model 1, PDM is simply a repository for information collected from CS and does NOT return any data back to CS. Campuses DO NOT have access to PDM. Particularly for CHRS, in Integration Model 1, CHRS is connected directly with the proper campus CS System for person adds/updates. CS will not provide any personal data adds/updates back to CHRS except for the User ID and BUSN Email but will send all personal data adds/updates to PDM.

• High Level Flowchart:

• For Integration Model 1, this provides a high-level view of how integration works.

Eventually all CHRS campuses will be under Integration Model 2. Under Integration Model 2, CHRS will no longer send person adds/updates directly to CS. Instead, it will send these transactions to PDM, and PDM will forward these transactions to the appropriate CS System. Changes within CS, including changes triggered by PDM transactions into CS, will send a person transaction to PDM. Integration Model 2 is not in production environments but is set to be the CHRS Integration Standard at a future date.

• High Level Flowchart – Changes in CHRS
  • Please note that PDM only sends data to CS when something changes in CHRS. However, CS will send data to PDM whenever data changes occur in CS, including applying the changes passed from PDM.

• High Level Flowchart – Changes in CS
  • Please note that PDM only sends data to CS when something changes in CHRS. However, CS will send data to PDM whenever data changes occur in CS, including applying the changes passed from PDM.

• For Integration Model 2, this provides a high-level view of how integration works.

• In the current model all personal data is synched both ways between the HR 9.0 system and its Campus Solutions (CS) 9.2 counterpart.
• Each person that exists in CS also exists in the corresponding HR system with the same Employee ID as their identifier.
• Changes that occur on either side are automatically replicated between the two systems and the person has the same Employee ID value in both.
• Campuses have access to setup full integration between CS campus owned support database, HR campus owned support database, CFS campus owned support database.
• Campuses are responsible for post-clone steps for CS campus owned support database, HR campus owned support database, CFS campus owned support database.

• In CHRS, synchronization will not exist where changes that occur on either side are automatically replicated between the two systems and the person has the same Employee ID value in both.
• All employees will still need to exist in Campus Solutions. Students and Applicants will no longer exist in CHRS unless they are also employees. People who exist in both systems will have different Employee IDs.
• Campuses no longer have access to setup full integration between CHRS to CS, CHRS to CFS.
  • Campuses needing full integration setup between CHRS production support to CS campus owned support database, CHRS production support to CFS campus owned support database. Will need to submit a ServiceNow ticket.
  • Campuses can set up CS to CHRS production support. CS campus owned support database to CFS campus owned support database, CFS campus owned support database to CS campus owned support database, and CFS to CHRS production support for campus owned masked environments.
  • Details about what campuses can set up regarding integration are in the Integration Configuration Guide in the Integration section of the CHRS Library.
• Campuses are not responsible for post-clone steps CHRS production support databased but are still responsible for CS production support databased.
  • It is recommended that campuses performing the post-clone steps in their CS test environment is to inactivate the CFS node after a clone. Since the domain in the CS instance is inactive after a clone then the only task is to inactivate the CFS node which can be performed by a script.
• When a person is created or updated in CHRS the data will flow to the Campus Solutions Database. Tables that are loaded in CS are:
  • PERSON – Just Birthdate
  • PERS_DATA_EFFDT – Just EFFDT and Update Information
  • ADDRESSES – All CHRS Types
  • EMAIL_ADDRESSES – HOME and OTHER
  • PERSONAL_PHONE – All CHRS Types
  • NAMES – All CHRS Types, includes Name Prefix and Suffix
  • PERS_NID
• When a POI is created in CHRS POI data is stored in CS. Currently only the POI type information is stored along with the effective date and status. The following are the tables loaded in CS:
  • PER_POI_TYPE - All
  • PER_POI_TRANS – Effective Date and Status
  • Note:
    • The view CSU_POI_INFO_VW pulls in SETID, DEPTID, BUSINESS_UNIT and LOCATION into CS.
    • Multiple POIs or POIs on more than one campus cannot have the same effective date when entered in CHRS and should never be backdated.

• Persons in the Campus Solutions systems have an Employee ID that uniquely identifies them within the application.

• In the current CMS model, each person that exists in HR will also exist in the corresponding CS system with the same Employee ID as their identifier. This will change in CHRS. All persons in CHRS will be renumbered and CHRS will create its own Employee ID that is different and distinct from the Campus Solutions Employee ID. This is necessary because someone can be an employee or student on multiple campuses.

• In CHRS, when an employee is created, a CHRS ID is generated, and it is sent to Campus Solutions, where a Campus Solution ID is generated. Then, a message is sent from CS to CHRS with the CS ID prepended with the two digit campus code. This value is stored in PSOPRDEFN in CHRS as OPRID.
• In addition, the EMAILID in this table is the Business Email address populated in CS and sent to CHRS.

• The campus code two digit code can be located in the CHRS Data Dictionary - CHRS Library  or in the Enrollment Reporting System Campus User Guide

• Page Up contains its own ID to identify a person called Applicant ID. Once a hire is successfully processed in CHRS using the CSU Recruiting Inbound Process the EmplID-UserID-ApplicantID Map table is updated. This is a read-only table that keeps the mapping of CHRS Empl ID, User ID (campus code + campus ID), and CHRS Recruiting Applicant ID. It is automatically maintained via Integration.
  • EmplID-UserID-ApplicantID Map Navigation: Menu > Recruiting > CSU Recruiting Processes > CSU Recruiting Inbound > EmplID-UserID-ApplicantID Map

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.

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.

• 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.

• 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

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.

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.

• 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. 

• CSUID Search – Searches all employees and POIs in the CHRS database.
• Student Hire – Searches all students at the campus using Database Links.

• CSUID Search – Searches all persons in the CS database.

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 

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

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.

• 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

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.

The Employee Salary Projection creates an output file for the FIRMS system.

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.

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.