This document provides users with answers to frequently asked questions about integration functionality related to the CHRS 9.2 upgrade and its integration with Campus Solutions (CS) 9.2 and the Common Finance System (CFS) 9.2.
Bio/Demo
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 Empl ID and BUSN email.
- Understand that 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 Empl ID and BUSN email.
- Keep in mind that CHRS has established standardized values that must be present in CS, and it is your campus's responsibility to ensure they are added.
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.
- Name Type
- Name Suffix
- Name Prefix
- AddressType
- Phone Type
- Email Type
- POI Type
It is the campus’s responsibility and should be done before their Pass A.
Yes.
All CHRS standardized configured types will be synced to CS (i.e. Name, Address, SSN, Phone, Date of Birth, POI Type, etc.)
The only data that CS will send to CHRS is the Campus Empl ID and BUSN email.
- Gender
- Emergency Contacts
- Date of death
- Marital status
- Military status
- Disability
- Disability accommodation
- Ethnicity/Diversity
- Citizenship
- Passport
- Visa/permits
- ITIN
Yes.
The CHRS Data Dictionary Section has a full list of the standardized values. However, for ease of access, we have included the values below that are finalized as of 11/5/2021.
- BUSN
- CELL
- FAX
- HOME
- OTR
- PGR1
- BUS2
- TDD
- HOME
- OTHR
- HOME
- OFFC
- PRF
- PRI
- PharmD
- Esq
- MD
- PhD
- I
- II
- III
- IV
- V
- CPA
- DC
- DDS
- DMD
- DVM
- EdD
- JD
- Jr
- OD
- OMD
- PE
- RN
- TTEE
- Sr
- VI
- VII
- VIII
- ADM
- CADT
- CAPT
- COL
- CMDT
- CDR
- Dr
- Fr
- Jdg
- LT
- LCDR
- MAJ
- Miss
- Mr
- Mrs
- Ms
- PRES
- RABI
- REV
- Sr
The ONLY data that CS will send to CHRS is the Campus Empl ID and BUSN email.
IB relies solely on the SSN to determine whether to assign a new Campus Solutions ID or link the hire to an existing one.
Using SSN only.
If the individual already exists in Campus Solutions without an and is then created in CHRS with an SSN, a duplicate record will be generated in CS.
Refer to the Managing Duplicates documentation for guidance on resolving duplicate records.
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.
- 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.
In PSOPRDEFN table located in the User Profile.
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:
| Campus Solution (CS) Table Name | Business Email Value |
| PS_EMAIL_ADDRESSES | BUSN |
| PSUSEREMAIL | BUS |
No, the Business email address does not go from CHRS to CS, it only goes from CS to CHRS.
| Scenario: | CS Tables Update | CHRS Tables Updated | |
| 1 | CS Business Email Address Inserted/Updated in Bio-Demo | PS_EMAIL_ADDRESSES (BUSN) and PSUSEREMAIL (BUS) | PSOPRDEFN and PSUSEREMAIL (BUS) |
| 2 | CS Email address Updated in PSOPRDEFN | PSOPRDEFN and PS_EMAIL_ADDRESES (OTH) | N/A |
| 3 | CHRS Email Address Updated in PSOPRDEFN | N/A | PSOPRDEFN and PSUSEREMAIL (BUS) |
For the Business email address, only the Add/Update a Person page in CS will update the PSOPRDEFN in CHRS.
| CS Page Name | Navigation | Updates PSOPRDEFN in CHRS |
| Add/Update a Person | Menu > Campus Community > Personal Information > Add/Update a Person | Yes |
| Electronic Addresses | Menu > Campus Community > Personal Information > Biographical > Addresses/Phones > Electronic Addresses | No |
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 Campus Solutions/
There is no different functionality between creating and entering someone new directly in Job Data verses creating someone new and giving them a POI. Both scenarios only send the BIO/Demo details to CS, and it is up to the campus to determine they need additional information through a DB link for a provisioning process (i.e., a User Profile in CS, a BUSN email, a specific report, etc.).
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.
POI Relationship details do not flow from CHRS to CS. Only the POI Type value flows with the person's Bio/Demo data and is visible in CS on the CSU ID Search page.
Yes, the POI Type and description should match exactly.
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.
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 CHRS Data Dictionary Section has a full list of POI Type and how they will convert.
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.
| Campus 1 | Campus 2 | CS Environment Updates |
| Active POI Only | No Association | Campus 1 |
| No Association | Active POI Only | Campus 2 |
| Active Job Record | No Association | Campus 1 |
| No Association | Active Job Record | Campus 2 |
| Active Job Record | Active POI Only | Campus 1 and Campus 2 |
| Active Job Record | Active Job Record | Campus 1 and Campus 2 |
| Active POI Only | Active POI Only | Campus 1 and Campus 2 |
| Active Job Record | Inactive POI Only | Campus 1 |
| Inactive Job Record | Active POI Only | Campus 2 |
| Active POI Only | Inactive POI Only | Campus 1 |
| Inactive Job Record | Active Job Record | Campus 2 |
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.
The only time a User Profile can be deleted, is if it is related to a duplicate.
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.
No
NO! Integration Broker only matches on SSN.
If the individual already exists in Campus Solutions with an ITIN and is then created in CHRS using that same ITIN, a duplicate record will be generated in CS. This new record will have a National ID Type of SSN and a placeholder value of 'XXXXXXXX' for the number.
Refer to the Managing Duplicates documentation for guidance on resolving duplicate records.
Integration Messages
Yes
| MSGNAME | APMSGVER | RECNAME | CHRS > CFS | CFS > CHRS |
|---|---|---|---|---|
| CHRS_ACCOUNT_CHARTFIELD_SYNC | VERSION_1 | GL_ACCOUNT_TBL | X | |
| CHRS_BUS_UNIT_GL_SYNC | VERSION_1 | BUS_UNIT_TBL_GL | X | |
| CHRS_CLASS_CF_SYNC | VERSION_1 | CLASS_CF_TBL | X | |
| CHRS_DETAIL_CALENDAR_SYNC | VERSION_1 | CAL_DEFN_TBL | X | |
| CHRS_DETAIL_CALENDAR_SYNC | VERSION_1 | CAL_DETP_TBL | X | |
| CHRS_FUND_CF_SYNC | VERSION_1 | FUND_TBL | X | |
| CHRS_JOURNAL_GEN_APPL_ID_SYNC | VERSION_1 | JRNLGEN_APPL_ID | X | |
| CHRS_LABOR_COST_DISTRIBUTION | VERSION_1 | CSU_LABOR_DIST | X | |
| CHRS_LEDGER_DEFN_SYNC | VERSION_1 | LED_DEFN_TBL | X | |
| CHRS_PAYROLL_ACCTG_TRANSACTION | VERSION_1 | CHRS_ACCTG_LINE | X | X |
| CHRS_PROGRAM_CF_SYNC | VERSION_1 | PROGRAM_TBL | X | |
| CHRS_PROJECT_SYNC | VERSION_1 | PROJECT | X | |
| CSU_PROVISION_INT | V1 | PSOPRDEFN |
CSU Exporting Accounting Lines
- HR_ACCTG_LINE-JOURNAL_LINE
- HR_ACCTG_LINE-JOURNAL_DATE
- HR_ACCTG_LINE-JOURNAL_ID
- HR_ACCTG_LINE-ACCOUNTING_PERIOD
- HR_ACCTG_LINE-FISCAL_YEAR
No. The messages that go between CHRS and CS will be primarily synchronous.
CS will only send CSU_PROVISION_INT (BUSN email) and CSU_SEC_USERID (CS Empl ID), which will include the ID for the User Profile and Business email.
| MSGNAME | APMSGVER | RECNAME | CHRS > CS | CS > CHRS |
|---|---|---|---|---|
| CSU_CHRS_CS_INTEGRATION | v1 | ADDRESSES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | EMAIL_ADDRESSES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | NAMES | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERSON | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERSONAL_PHONE | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERS_DATA_EFFDT | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PERS_NID | X | |
| CSU_CHRS_CS_INTEGRATION | v1 | PER_POI_TYPE | X | |
| CSU_SEC_USERID | v1 | CSU_SEC_CHRS | X | |
| CSU_PROVISION_INT | V1 | PSOPRDEFN | X |
In CHRS, archiving and purging follow a standardized approach. Archiving occurs automatically for Synchronous and Asynchronous Integration messages older than 14 days in a “Done” or “Cancel” status. Purging, for Synchronous and Asynchronous Integration messages will be every 40 days or during system upgrades.
No. Campuses are not required to modify their Campus Solutions database to match CHRS standards. However, they should ensure that their process retains messages for at least 2 days to support troubleshooting.
In CHRS, campuses do not monitor Synchronous or Asynchronous Integration messages. Instead, the CMS team monitors these messages using Nagios.
Campuses are not responsible for monitoring CHRS integration errors—that responsibility belongs to CMS. However, campuses are responsible for monitoring their Campus Solutions (CS) for integration errors.
- Has a duplicate record been created (which might cause login or profile issues)?
- Have I reviewed integration setup and checked synchronous/asynchronous message logs in CS for errors during the relevant time window?
Job Aid: Integration Troubleshooting Guide
The CSU IB Monitor in CHRS, campuses are able to gain VIEW ONLY access into the status of integration configuration along with Synchronous and Asynchronous Integration transaction.
Job Aid: CSU IB Monitor in CHRS
The Integration Troubleshooting Guide provides campus users with assistance in troubleshooting integration errors that occur in CS or CHRS.
Job Aid: Integration Troubleshooting Guide
Multi-Campus Employees
A Multi-Campus Employee, also known as a Shared Employee, is an individual who works or has worked at multiple CSU campuses. In terms of integration, there is minimal impact—Bio/Demo updates made in CHRS will flow to Campus Solutions (CS), provided the POI or employee is active and has a User Profile established at each campus.
In CHRS, a campus can only view an individual's Bio/Demo information in Modify a Person if there is an existing association with that person (e.g., a POI or Job Record). For an POI or employee that already exists for another campus, once the hiring campus creates a POI or Job record, that campus will be able to see Bio/Demo information in Modify a Person. At this time a User Profile will be created for that campus as well. Once Bio/Demo details are updated—whether via Self Service or Modify a Person—the changes will be shared with all associated campuses in Campus Solutions (CS), as long as the campus association (e.g., POI or Job Record) is active in CHRS.
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.
Start by using the CSU ID Search to identify whether the individual has a POI record, a Job record, or both with another campus or multiple campuses.
Job Aid: Find Employees with CSU ID Search
If a campus identifies that the individual they are hiring is already associated with another campus as a POI, and the existing POI type is one for which the hiring campus has provisioning configured, they can build on that existing POI. Otherwise, the hiring campus must create a new POI record using a POI type of their choice
Job Aid: Add a POI relationship to an existing person (Create POI Record)
Job Aid: Maintain a POI Relationship (Stack on existing POI Record)
If the hiring campus determines that the individual already holds a Job Record at another campus, they may choose to create either a POI record or a Job record.
Job Aid: Add a POI relationship to an existing person (Create POI Record)
If a campus identifies that the individual they are hiring is already associated with another campus as both a POI and with a Job Record, the hiring campus has two options: they can create a new Job Record, or—if the existing POI type is one for which they have provisioning configured—they may build on that existing POI. If not, they must create a new POI record using a POI type of their choice.
Job Aid: Add a POI relationship to an existing person (Create POI Record)
Job Aid: Maintain a POI Relationship (Stack on existing POI Record)
ID Search
- In CHRS, the CSU ID Search will only display CHRS Empl ID.
- In Campus Solutions, the CSU ID Search will only display CS Empl ID.
- CS Navigation: CSU SA Baseline > CSU Campus Community > CSU ID Search
Yes, it is CSU_CHRS_XREF.
Yes, the CHRS Cross Reference Table can be located using the following navigation:
CSU SA Baseline > CSU Campus Community > CSU Cross Reference to search a person online in CS
Campuses will have to rely on the CHRS Cross Reference Table on their CS side.
Yes, but they should not the CHRS OPRID is <campus code> + CS ID
Security
Campuses are required to create roles and permission lists in CS for the CHRS Cross Reference, CHRS Cross XRef Table, and HR Table Refresh.
No, Campuses will need to develop their own role or add the CSU_CHRS_XREF page to an existing role.
Campuses are required to create roles and permission lists in CS for the CHRS Cross Reference and CHRS Cross XRef Table. This is the permission list information needed:
Menu: CSU_CHRS_INTEGRATION
all components
all pages
all actions
Campuses are required to create roles and permission lists in CS for the CHRS Cross Reference and CHRS Cross XRef Table. This is the permission list information needed:
Menu: CSU_CHRS_INTEGRATION
all components
all pages
all actions
Campuses are required to create roles and permission lists in CS for the HR Table Refresh. This is the permission list information needed:
Menu: CSU_CHRS_INTEGRATION and CSU_INTEGRATIONS
all components
all pages
all actions
Users will need a total of 2 roles:
- CMS_PT_CSUCSHR
- CMS_PT_ENABLE_CI
The roles are delivered in CS008 and can be granted to a campus once CS008 is applied to the campuses CS production during the CHRS MTP.
Campus DO NOT have a role in CHRS to view Asynchronous and Synchronous messages. Due to the Level 1 data imbedded in the Asynchronous and Synchronous messages in CHRS, only those in CMS will have access.
Campus are always welcome to submit Change Controls. However, due to the Level 1 data imbedded in the Asynchronous and Synchronous messages in CHRS, a Change Control will not be approved.
End of Article