Background

A Person of Interest (POI) is an individual that has a relationship with the campus in several capacities for various business needs and interests but are not part of the workforce. The typical business practice in appointing POIs was to obtain confidential personal data (e.g., Social Security Number (SSN), International Tax ID Number (ITIN)) to enable the POI to obtain provisioning at the campus. Campuses utilize POI types within Oracle/PeopleSoft to track volunteers, Emeritus Faculty, applicants, foundation/auxiliary personnel, and individuals that serve in numerous other capacities based upon campus needs. Prior to the split of HR and Campus Solution (CS), POI types were appointed through HR or CS functionality; in CHRS, POIs will be processed through HR. Typically, once the individual is established as a POI and assigned an Identification Number (ID) in the system, they are given access to a host of respective campus services and provisions, e.g., shared networks, e-mail accounts, library services, parking, keycards, learning and development and training purposes, parent portals, etc.  This will change only with respect to CS-related provisioning, which will not be available in CHRS. Standardized processes are needed to ensure that campuses add POI data within CHRS uniformly and consistently. The system business need that supports the requirement for collecting SSN/ITIN and Date of Birth is to reduce the number of duplicate EMPLIDs in the system. For HR, business requirements for collecting this data are as follows:

1. the vast majority of volunteers are required to complete a background check, wherein both the SSN/ITIN and DOB would be required.
2. we are required to cover volunteers, just like employees, under CSU’s workers’ compensation insurance program. In the event a volunteer is injured while performing their volunteer work, we would need this basic information as well as their emergency contact.

If you are having trouble obtaining SSN/ITIN, contact your HRO for guidance.

If anyone needs to be put into PeopleSoft as a POI to enable services or tracking at the campus, then the requirement will be to collect SSN/ITIN and DOB to ensure the quality of our data. If no services are required, the campus can determine how to collect and manage required volunteer information outside of the system, while adhering to pertinent policies and guidelines.

This position paper addresses changes to POI security and functionality for CHRS. It identifies the standards for data values moving forward and includes details on a change in business process and security of the Maintain a POI Relationship page. 

Issue

Security

The delivered process for POI security in PeopleSoft 9.0 is cumbersome and requires a huge manual effort. Delivered security is by permission list and requires every department in which security is needed to be entered for every POI type and for every row level permission list. 

Functionality

In PeopleSoft 9.0, Planned Exit Date is not required, and the Status field is manually updated, leading to inaccurate and inconsistent data. 

Combined environment magnifies potential for duplicate EMPLIDs and underscores the need to ensure the quality of our data in a shared environment. 

Data Values

There are 99 unique POI types in the current 9.0 environment comprised of 31 delivered, or baseline, values, and 68 that have been created by campuses.  Of the campus-specific values, many are similar from one campus to another with only slight variations in the code descriptions.

Analysis

Security / Functionality

When addressing the functionality of the Maintain POI Relationship page, three options were discussed as it relates to the Security grid and History grid.

Option 1: One Security Data Row one history row by campus.  Limit Security Row to one per campus – if changes are needed, to exit date, use correction mode, no history – this does not allow for maintaining history by campus. 

Option 2: Redesign page so that the Security data section is tied to the history section.  Allows multiple rows in history, by Campus Security data row – This would be the cleanest way, however it would require a redesign of the page. Significant modification.  Example shows there are 2 Security data rows, for two campuses, but the history shown is attached to one security data row.

Option 3*: To maintain require campus to add a row to security data, therefore maintaining the one security row to match one history row.  If we can hide the +/- on History this would be recommended option, as it requires minimum customization, yet delivers the history requirement. This will ensure that we have one row of security for each row of history.  Without the +/- the user would have to add a row on top consistently if they wanted new information on the bottom.  Less chance of error.  Without hiding the +/- buttons, it gets confusing when trying to add history, and results in error messages.

*Option 3 was approved for CHRS as it recommended following best business practices and will support how history is currently being kept at some campuses.

Data Values

In order to reduce the number of values in CHRS, the Data Standardization Workgroup surveyed campuses through meetings with Campus Conversion Partners and Campus Data Coordinators to find out if codes could be mapped or inactivated altogether. After analyzing their responses, the list of standardized values for CHRS was reduced from 99 to 68 standardized values.

Recommendations

Security

The new process will use the end user’s existing department level security for POI on the Modify a Person page containing level one data, and security will be removed from the Maintain a POI Relationship page.  All POI’s will now be visible and editable by all campuses with ps_audit turned on to track any changes or deletions, but additions will not be audited.  There will be a process that will archive old audit data that can be queried.  The new audit tables can be found in Appendix B at the end of this document. 

In security data, the POI Department row must be completed. There will also be a location access type row which is not required.

A new effective dated row will be added to the POI History grid every time a new row is added to the Security data grid.  The process will be the same for record deletion; when a row is deleted from the Security grid, the corresponding effective dated row will be deleted from the History grid.

Functionality

The Status field on the History grid will update automatically upon saving any updates to the Planned Exit date.  For records that are not manually updated, a nightly process will run and update the status field accordingly.

A Planned Exit date will be required which eliminates the need for status date. The definitions of an ‘Active’ and ‘Inactive’ POI will be derived from the difference between today’s date and the Planned Exit date; if today’s date falls between Effective date and Planned Exit date, the POI is Active and if not, it is Inactive. Applying this logic, Planned Exit date will be used to automatically update the Status field to A for Active or I for Inactive, and can be referenced for provisioning and deprovisioning access in other systems.

Also, two fields have been added to the Maintain POI Relationship: "Reports To" and "Title". Neither of these fields are required.

CHRS Readiness

The only records that will be converted into CHRS will have all of the following:

• The most current row will be the only row to be converted per POI type per campus.
• Every POI must have a Social Security Number (SSN) and Date of Birth (DOB)
• All POIs must have a completed POI Department Security access type, on the most current row. The department must be in the DEPT_SECURITY_TREE.
• Every POI will need an Effective date and Planned Exit date.
• Since status will be derived from the Planned Exit date, the Status will not need to be active.

As discussed above, the list of POI Type values for CHRS has been reduced from 99 to 68.  There is no need to map to new CHRS values; this will be done during conversion. See Appendix A at the end of this document.

Considerations

1. The purpose of the Planned Exit Date will be to ensure that security access is turned off when no longer needed. Therefore, with the exception of Emeritus, Planned Exit Date should not be too far into the future.  Going forward, it would be campus decision on how long a POI type should be granted access and campus rules should be established. Campuses will be able to review these dates at intervals that adhere to their guidelines.

2. When adding a new row for security data, users will get both POI Dept and Location.  Note that Location will not be required, but it will remain even if it is not populated (see screen shot below).  This will be helpful for any campuses that are using Location and wish to populate it.

   

Cross-Functional Impacts (Positive / Negative)

All values for each POI will be consistent amongst all campuses and available for any downstream systems.

CHANGE IMPACT

To be filled out by BSA (from Change Impact Tracking log):

The following impact areas should be addressed by the Position Paper author(s) or a relevant stakeholder/approver.  All items should have a response.

1. Areas of potential change resistance to proposed HR process / policy changes?

   There may be potential change resistance to requiring SSN, DOB, and a planned exit date and department to ensure successful data conversion into CHRS.  For some campuses, this will be a huge change to their current business process.

2. Potential resource needs in order to plan, engage, prepare, and/or deploy the change?

   Resource needs will depend on the number of records that need to be updated for conversion.

3. Associated costs relative to the scope of the change to requirements requested?

   Associated costs are relative to the time needed for number 2.

4. Training needs or if a straightforward change?

   Refer to the POI functional spec for details on Security and Functionality updates.  SQL can be written by campuses to assist with clean-up to comply with the requirements under CHRS Readiness.

5. Implication on any other related process / functions?

   None

6. Union impact? Any additional comments (from Labor rep)?

   No reasonably foreseeable impacts within the scope of bargaining identified at the time of review.

REVISION CONTROL

Revision History

Review/Approval History

APPENDIX A:  POI Value Mapping for CHRS

Respondent Sources:

• Standardization Workgroup, January 2019
• Campus Conversion Partners Survey, Feb-March 2019
• Campus Data Coordinators Survey, March-April 201

Updates:

7/2/20 - corrected mapping of code 00111 (was 00107 in error)

12/14/2020: 

Codes 00330 and 00909 are duplicates, inactivate 00330.

Add new code 00339,  to replace 00007 (needs to be removed in CHRS)

Inactivate 00008.  Keep 00300 (same name)

Inactivate 00011-Other Payee. No replacement needed.

00111 needs to be added to STG

Position paper updated 1-21-21

2/2/23:

Change mapping of code 90001 to map to 00034.

Sent to Sudhakar 2/2/23

Update position paper 2/2/23

6/28/23:

Change mapping of 00299 to map to 10012 instead of 00315.  00299 will not carry forward.

Change mapping of 10012 campus specific code (Chico) to 00315 (was 00299 in error)
 

APPENDIX B:  CSU_POI Security Audit Tables

End of Article