CHRS Integration(9.0, IB, PDM) -This document is intended to help campuses understand how integration will be changing for CHRS, and analyze their current HR, campus-specific integrations and define which ones will be delivered with CHRS. Any integration necessary for a campus to function and not delivered by CHRS must be documented and approved by CHRS management before it can be developed and implemented by CHRS.

DB Link Details - 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. Campuses should review all areas where database links are used and determine retrofits. This document provides an overview display of what tables/view are accessible between CS, CHRS and CFS. 

What Data Goes between CS/CHRS and CFS/CHRS (High Level) - This document is intended to help campuses understand what data goes between CS/CHRS and CFS/CHRS.

Integration Data Flow (High Level) - A high level overview of how details flows between CHRS and CS using Integration Broker. 

Integration Frequently Asked Questions (FAQ) - The purpose of this document is to provide users with responses to frequently asked questions about different aspects of the Consolidation and Upgrade of Human Resources (CHRS) 9.2, application integration, impacts to integrating with Campus Solutions (CS) 9.2 and Common Finance System (CFS) 9.2.

As you continue to learn about the integration functionality between CHRS and both CS and CFS, it’s important to involve stakeholders from CS and CFS—not only to familiarize them with the changes, but also to support testing, retrofits, and any necessary modifications. 

It is critical that campuses closely monitor integration errors in HR 9.0, CS, and CFS. During the CHRS go-live, campuses must ensure all messages are in a 'Done' status for HR 9.0, CS, and CFS. Once the campus transitions to CHRS, these error messages will no longer be available for review or resolution, as messages between CS and CHRS will be processed synchronously.

Campuses will need to adjust their provisioning processes in CS when implementing CHRS. Some areas that will require modifications to the provisioning process include:

• Business Email
• Business Phone
• User Profile creation in CS

Campuses should review all CS custom modifications and compile a list of all tables used. Next, they should assess whether each table is 'owned' by HR. Once the assessment is complete, campuses will need to make the necessary changes in CS to ensure that functionality is available once CHRS is live. Some examples of campus customizations are: 

• Updating preferred name
• Auto-creating POIs in HR
• Updating Business Phone
• Updating Business Email
• AAWS Web Services
• Synchronizing home address for reporting
• Duplicate ID Deletion
• Load Runner to Update Addresses
• Scheduled Reports Utilizing DB Links
• CSU ID Search

When a campus goes live in CHRS, the CS database will be temporarily unavailable to allow for the application of CS008. This update will modify certain functionality in CS. Campuses with custom modifications should pay close attention to these areas to ensure compatibility and proper functionality post-go-live.

• CAAR Advising Report
• ALMA
• Add Application/CSU Apply
• Assigning instructors to classes
• Work study processing
• Student/Faculty Self Service  

When a campus goes live in CHRS, the CS database will be temporarily unavailable to allow for the application of CS008. After CS008 is applied, campuses will need to create and assign the appropriate security roles within CS. 

It is the campus’s responsibility to monitor their CS/HR 9.0 environment for duplicates. As you transition to CHRS, duplicates will be managed differently. It is crucial to ensure that no duplicates are converted during go-live, as resolving them afterward will be challenging. Once in CHRS, the definition of a duplicate and the process for handling them will differ.

Person/User ID Delete - The purpose of this document is to provide campuses with guidance on Person and User ID Delete in CHRS. As the process in CHRS is different. In HR 9.0, campuses had full control over deleting the Persons and User IDs from the system. Often those that were deleted were due to data entry errors, duplicates, a person declining an offer, etc. In CHRS, campuses do not have the ability to delete a Person or User ID and must submit a ServiceNow ticket requesting for the delete. Often those deletes are related to a duplicate. A duplicate can be created in CHRS and Campus Solution (CS) as an Empl ID or User Profile. Duplicates can be created manually or by using CHRS Recruiting (PageUp) Staging Table in CHRS. Duplicates are primarily created because the Social Security Number (SSN) was entered incorrectly. 

Job Aid - Pending

Integration Troubleshooting Guide - The purpose of this document is to provide campus users with assistance in troubleshooting integration errors that occur in CS or CHRS. Depending on the database the error occurs, different resources will be responsible for troubleshooting and resolving. 
CSU IB Monitor - With the CSU IB Monitor, campuses are able to gain VIEW ONLY access into the status of integration configuration along with Synchronous and Asynchronous Integration transaction.  

Requesting CHRS environment to connect to CS environment - Guidance for production campuses on the steps to follow when requesting a non-production CHRS database connection to their own masked Campus Solutions environment.

Job Aid - Pending - Connect CS to CHRS (DB Link)

Job Aid - Pending - Requesting a CHRS environment to connect to a CFS environment

When CHRS, CS, or CFS is down for upgrade, maintenance, application of MPs, production campuses during wave implementation (several days) or some other reason, integration can be impacted for one or more campuses depending on the circumstance. When integration is impacted, it is recommended that campuses complete the integration checklist to ensure integration is working as expected when systems are returned. 

Campus Integration Validation Checklist (Without CMS)