When CHRS database is down for upgrade, maintenance, application of MPs, Wave implementation (several days) or some other reason, specific steps are taken to ensure minimum impact to the CS and CFS environments.

1. CMS in CHRS will review both Synchronous and Asynchronous Messages to confirm NO errors
2. CMS will work directly with CO Tech Services for CHRS to have
   1. All job processes PAUSED for ALL Campuses
   2. The campus’s production CS environments temporarily connected to a false CHRS production environment through a DB link. (Note: The CFS environment will remain unconnected)
   3. To use “lock and unlock” scripts to prevent all employees/POIs from accessing CHRS during the maintenance.
3. Campuses will need to communicate to campus employees/POIs about the upcoming maintenance for CHRS and encourage all employees/POIS to make any personal data updates in CHRS prior to the maintenance.
4. In CS, campuses will need to:
   1. Pause Automated Processes (BUSN Email Previsioning, Schedule Jobs, etc.)
   2. Review both Synchronous and Asynchronous Messages to confirm NO errors
5. In CFS, campuses will need to:
   1. Review Asynchronous Messages to confirm NO errors

To ensure that the campus’s production CS environment is not impacted by the CHRS maintenance. Without the connection the campus’s production CS environment would have functionality that would fail and impact the student population.

The following would be impacted:

• Assigning instructors to classes
• Work study processing.
• Personal Data cannot be saved in CS-Admissions will not function.
• Student Center (baseline may need a modification to address this).

The following would be impacted:

1. Adding / updating ChartFields: Fund, Account, Program, Project, or Class
2. Journal generation of HR data from the HR_ACCTG_LINE table which published the journal ID back to CHRS
3. Messages will error out and Campus IB Administrators will need to resubmit the messages when HCHRPRD IB is back up

If the CHRS database is down, then a notification will be sent to the campuses and no Asynchronous or Synchronous messages will go in or out of CHRS.

Yes

•  Yes, the CHRS Non-PRD Clone Schedule is located here.

When a CS campus is down for upgrade, maintenance, application of MPs or some other reason, specific steps are taken to ensure that only the campus going through the maintenance is impacted.

1. Campus will need to provide “lock and unlock” scripts for both employees and POIs. The “lock and unlock” scripts will need to be for both CHRS and CS environments. The “lock and unlock” scripts will need to be provided to the Upgrade Team.
2. Campus will be responsible for communicating to their employees/POIs and shared employees/POIs about the upgrade.
3. Inform active shared employees or shared POIs with a connection and/or relationship to other CHRS campuses
4. CMS will work directly with CO Tech Services for CHRS to have an update made to the “URL Maintenance Page” for the campus going through the CS upgrade to prevent the campus employee/POI and shared employee/POI from making personal transactions updates during the downtime.
5. CMS will work directly with CO Tech Services for CHRS to the following three job processes during CS Solutions PeopleTools Upgrade window will be PAUSED for ALL Campuses
   • CSU Employee Refresh
   • CSU POI Status Update
   • CSU Workstudy Data Refresh

A variety of locations through CS will fail without the DB link from CS. For example 

• Add/Update Person

If the CS database is down, then no Asynchronous or Synchronous messages will go in or out of CS.

When a CFS is down for upgrade, maintenance, application of MPs or some other reason, all CHRS DB Links will fail and all Ayshcrnonous messages will go into a queued state until they can be resubmitted. 

The CHRS App Dev team will be responsible for resubmitting all Ayshcrnonous messages in CHRS when able. 

All CHRS DB Links will fail and all Ayshcrnonous messages will go into a queued state until they can be resubmitted. The CHRS App Dev team will be responsible for resubmitting all Ayshcrnonous messages in CHRS when able. 

Integration is a one directional sync between CHRS and CS. This means that Bio/Demo will go from CHRS to CS, but not from CS to CHRS. The only data that CS will send to CHRS is the Campus ID and BUSN email.

All CHRS standardized configured types will be synced to CS. PDM will be a depository for that data.

Review all areas where values are used and determine retrofits. This would include provisioning tools, Search/Match (gender, birthdate) and other third parties that utilize unsynced bio/demo data for faculty/staff. Ensure all CHRS bio/demo types listed above exist on field or translate tables in CS and are active.

1. Gender
2. Emergency Contacts
3. Date of death
4. Marital status
5. Military status
6. Disability
7. Disability accommodation
8. Ethnicity/Diversity
9. Citizenship
10. Passport
11. Visa/permits
12. ITIN

Yes.

CHRS is the system of record for preferred name for faculty, staff, and student workers. Preferred name updates will sync from CHRS to CS. No updates from CS will go to CHRS.

Student workers who update their preferred name in Campus Solutions will not update CHRS. Student workers will need to update their preferred name in CHRS also.

The employee must be active for the information to feed from CHRS to CS. If the employee is active at multiple campuses and their personal data is updated for one of the values that integrates from CHRS to CS, then it will update all CS environments the employee is actively associated with and not just the primary campus.

• Baseline delivered integration broker messages between CS (updated via Add/Update a Person) and CHRS will update this value on the PSOPRDFN table but does not update the CHRS Email bio/demo value. Updating Business Email on CHRS via Self Service or Bio/Demo is disabled.
• Business Email (BUSN email type only) will be sent from CS to CHRS over to the PSOPRDFN table as the EMAILID.

For provisioning, campuses should review usage of Business Email. Integration from CS to CHRS for the Business Email will only work if the Business Email in CS is updated on the “Add/Update a Person” component and not the Electronic Addresses component.

In CHRS, the PSOPRDEFN table houses the BUS email type for individual campus User IDs. This value is populated by Campus Solutions campus provisioning when the BUSN email type from PS_EMAIL_ADDRESSES is populated (or when manually updated on Campus Solutions’ Add/Update a Person)

 No, Business Email Addressed cannot be created/updated in Modify Person.

The following CS tables should the following value:

No, the Business email address does not go from CHRS to CS, it only goes from CS to CHRS.

For the Business email address, only the Add/Update a Person page in CS will update the PSOPRDEFN in CHRS.

The code is in CSU_CHRS_INTEGRATION.Provisioning.ProvisionIntegrationOneID to send an updated Business email in CS to CHRS

Yes, all faculty/staff/POIs created in CHRS will exist in PDM and Campus Solutions

Yes, when a CHRS employee and/or POI is created on the CS side, another student POI Type of 0009 “CS Person” will be auto created during the creation of the CS EMPLID.

 The key is that the POI Type must at least exist on the CS side for the integration to be successful. If an inactive POI Type is used in CHRS, the integration process will still be successful, and a User Profile will be created in CHRS.

The user will appear on the CS side with a “Future Hire” POI Type and not the POI Type they were created with in CHRS. A User Profile will NOT get created in CHRS side.

No, if a faculty/staff/POI is created in CHRS for one campus, then only that campus CS environment will receive the created faculty/staff/POI.

Nothing will happen. The new campus will have a User Profile created in CHRS, and both CS environments will be updated with the Bio Demo changes.

 If an employee and/or POI exists at multiple campuses and a change is made to their BIO Demo, then certain campus CS environments are updated. Use the chart below to see the different scenarios. 

An Unknown POI Type is created when the process of creating the user as a POI or in Job Data was not fully completed. This can occur through CHRS Recruiting or by manual entry. For example, a user entering a new employee manually on the Add a Person page presses save and exits the page before completing the Organizational Relationship section.

Once an Unknown POI Type is created, the IB process will fail, and a User Profile will not to be created on the CHRS side. To resolve this, the campus will have to either create the user directly in Job Data or add another POI Type to the user. Once that is done, the IB process will be successful and a User Profile on the CHRS side for the User Profile to be created. There are some cases where the campuses will not be able to resolve the Unknown POI and will need to open a ServiceNow ticket. 

A POI can be backdated if the required date is the same as the Effective Date of the Name and does not have associations with other campuses. However, the integration will send the bio/demo details to CS will the current effective date. 

No. POIs who exist in multiple campuses cannot be backdated when POIs are created in the CHRS database. They will be locked by SETID and will be synched with the campus to which it has been assigned – by the SETID / Department. Each campus will see their own POIs assigned by campus departments.

No, CS will always have a current effective date regardless of what has been entered in CHRS.

No. The CHRS System does not allow for future dated entry.

The User Profile Role will no longer be synchronized between CHRS and CS. When a person is created in CHRS, their User Profile will not be automatically created in CS.

Roles assigned in User Profiles will not sync between CHRS and Campus Solutions. Campuses that rely on roles syncing will need to review impacts/alternatives to business processes.

The persons will have one ID in CHRS and different IDs in CS environments. In CHRS, the CS ID is found on the User Profile Page with a prefix of the campus code found on COSAR Table 01. Persons existing in multiple CS campuses will have multiple User Profiles in CHRS.

During the implementation conversion everyone receives a User Profile, except for those that are deceased. After conversion everyone receives a User Profile, if one needs to be deleted then a ServiceNow ticket is required.

Yes.

 In CHRS, when an employee is created, a CHRS ID is generated, and sends the information to Campus Solutions, where a Campus Solution ID is generated. The generated Campus Solutions ID is then, sent from CS to CHRS with the CS ID prepended with the two digit campus code which is stored in PSOPRDEFN in CHRS as the OPRID.

 In CHRS, once a User Profile is created through integration, it cannot be recreated. This means, that a User Profile must remain connected to the employee even if they are no longer connected to that campus. If the User Profile is deleted, it would have to be manually recreated. 

No! A User Profile is NOT automatically created in Campus Solutions. If campuses want an employee/POI to have a User Profile in CS they either need to manually create or have a process established that creates user profiles in CS.

The CS Baseline Work Study modification utilizes CSU_PIP_HISTORY to determine how Much money students have available for financial aid disbursement. The CHRS table JOB will be converted as of November 1, 2019. Currently, at least 10 campuses use this modification.

In CHRS, 7 campuses (CI, EB, FRE, LA, LB and SF + CO) had their Company changed (CIS, EBY, FRE, LAS, SFO, CHO). Many went from a 2 digit codes to a 3 digit code.

For CS, baseline has developed views that utilize the COMPANY conversion. Campuses should review all areas where COMPANY used and determine retrofits.

CSU_PAY_CHCK_VW has been created to blank out the SSN field, making it so that the SSN is no longer available on this record (view). Campuses will need to review all areas where PAY_CHECK is used and determine retrofits. As CS will link to the new view and only have access to that view through DB links.