In a consolidated HR 9.2 instance, the user profile will be structured with a two-digit campus code as a prefix, followed by the person’s campus ID, typically consisting of nine digits. The campus ID, also known as EmplID, is assigned within the Campus Solutions system. This naming convention ensures unique identification of user profiles within the consolidated HCM 9.2 system, facilitating seamless integration and data management across the campus network.

For Example:

• User Profile = 2 digit campus code + campus ID (current campus CS/HR ID)
• Format: CCXXXXXXXXXX total of 11 digits
• 40 = Long Beach
• 50 = Fullerton

Each campus will have one template user profile that serves as a blueprint for all employees within their respective campus. Using a custom Create User Profiles Batch process, this template profile will be duplicated and assigned to each employee, ensuring consistent base permissions as defined by the campus. Notably, the password field in these user profiles will remain unset since all users will utilize single sign-on authentication to access HR 9.2.

A business email type will be added if one is available when the process is run.

The custom Create User Profiles process will link the newly created user profile with the new CHRS Empl ID.

All template user profiles will be assigned a base role called CHR_PT_PeopleSoft_Users, which provides the minimum access necessary to use HCM 9.2. Campuses have the flexibility to include additional roles as needed.

Settings on the Workflow tab.

The campus security administrators will have the ability to manage user profiles exclusively for their respective campuses. This is accomplished through a combination of delivered configuration. After the go-live phase, the integration process between HCM 9.2 and Campus Solutions will automatically generate new user profiles for newly hired employees.

The campus security administrators will have the ability to update and modify the attributes of user profiles.

Navigator Homepage – Although not currently utilized in HCM 9.2, it is recommended to have a campus-specific permission list in place for future use. This permission list can be customized to align with the unique security requirements and access needs of each campus within the HR 9.2 system.

Process Profile – Two permission lists are available for campuses to manually grant users that require additional permissions for running batch processes through PeopleSoft Process Scheduler. For example, the process profile is where users are authorized to view output, update run locations, restart processes, and so on.

• To determine which user profile may require a different Process Profile permission list, campuses can query HR 9.0.
  • SELECT A.PRCSPRFLCLS, COUNT(*)
  • FROM PSOPRDEFN A
  • GROUP BY  A.PRCSPRFLCLS
• Process Profile Permission List: CSU_PRCS_PROFILE_OWNER_RECUR

Process Profile Permission List: CSU_PRCS_PROFILE_OWNER

Primary – Each campus will have its own Primary Permission List following the naming convention (campus 2 letter abbreviation followed by PPHRLEAD.

• In HR 9.2, the primary permission list is linked to:
  • Application definition security – CSU will use Definition Security to secure campus trees by SetID. Users that will maintain or need to view the DEPT_SECURITY and the CHRS_HIERARCHY trees will need to have the xxPPHRLEAD permission list set on the Primary field on the User Profile.
    • Definition Security to Secure Trees document
  • Organization default in HRMS – Setup HCM>Foundation Tables>Organazation>Org Default by Permission Lst.

The Time-out Minutes is set on the permission list - PeopleSoft>Security>Permissions & Roles>Permission Lists>

To determine which user profile may require a different Primary permission list other than the default, campus can query HR 9.0.

• SELECT A.OPRCLASS, COUNT(*)
  • FROM PSOPRDEFN A
  • GROUP BY  A.OPRCLASS

Note: In HR 9.0, the Primary permission list provided users with access to view the complete values of the Social Security Number (SSN) and Date of Birth (DOB). However, in HCM 9.2, Oracle has introduced Data Masking, which is role-based. Users who require full view access should be granted one or more of the roles listed below. More details about managing roles can be found in the subsequent section.

Row Security – Row Security permission lists provide data-permission security based on a department security tree. Data permissions can be assigned to permission lists on the Security by Dept Tree page. During the conversion process, the Row Security field will be populated based on the user's settings in HR 9.0. However, after go-live, it will be the responsibility of the campus to manually maintain this field.

Each campus will have a dedicated Distributed Security Administration role. This role will grant the Distributed Security Administrators (DSA) the authority to manually assign authorized roles to users within their respective campus. The provisioning and deprovisioning of the campus-specific Distributed Security role will be handled by Systemwide Human Resources. Any changes or modifications to the role should be requested through the ServiceNow platform by the campuses.

The execution of role rules is carried out by the DYNROLE_PUBL application engine program, which is scheduled to run hourly through PeopleSoft Process Scheduler. The program runs on weekdays hourly starting from 4:00 am to 8:00 pm. Within CHRS, there are multiple roles that have the Query Rule Enabled option enabled.

Recruiting roles are PeopleCode Rule Enabled. Further details can be found in the CHRS Dynamic Role document.

A list of authorized roles for each campus can be downloaded from the Role Grant tab on the Role page using the Grid Action Menu icon. Please note that the list includes both dynamic and static roles. It is important to periodically review and manually remove any dynamic roles that have been added to a user profile.

These roles are specifically designed for provisioning and deprovisioning access within the PageUp system. It is important to note that only one Recruiting role should be assigned to each user profile.

There is a nightly process managed by CMS that pulls users assigned to these roles for PageUp. This process runs from Sunday to Thursday at 5:30 pm. Upon execution, the process generates an error report that each campus must review and take necessary corrective actions.

The recruiting roles are prefixed with "CSURSPU%". Campuses can choose from five PeopleCode Enabled Rule recruiting roles and write their own role queries for each role. Additional information is provided in the CHRS Dynamic Roles document.

Please be aware that the roles listed in the matrix below do not grant access to PeopleSoft

CSURSPUApprover Approver-Budget When appears in the approval process, can approve job, PD and offer card, as well as edit Budget sections. Can also function as search committee member, with ability to compile application material, when named as a search committee member on the Job Card.

CSURSPUApprover-Budget Approver-Budget Same access as CSURSPUApprover-Budget for job card and applicant access. The difference is this permission will carry user's department access from PS into PU, so when running a report, the result can be from more than their own department.

CSURSPUApproveClassComp Approver Class Comp When appears in the approval process, can approve job, PD and offer card, as well as edit classification related fields. Can also function as search committee member, with access to compile application material, when named as a search committee member on the Job Card.

CSURSPUCampusConfigAdmin Campus Config Administrator Highest level of permission at campus level. Limited to 2 per campus after go-live. Can access all functions as a Lead Recruiter, in addition to access to system configuration.

CSURSPUCompliance Compliance Facilitator Special permission designed for EEO Diversity Officer. Can also function as a search committee member with compile function. No need for this permission if just to run EEO report. However, this permission is needed to review applicant information and job information throughout recruitment..

CSURSPURecruiterI Recruiter Limited Name must be associated with Job Card as the HR/Faculty Affairs Representative. Function as the Manager of recruitment and campaigns, with limited access to configuration. Can access to talent search and CRM. Can access applicants in all applicant status. Can edit approval process and can edit job after approval.

CSURSPUSearchChairI Search Committee Chair When name is identified as Search Chair on Job Card, can review other search committee members feedback on applicants. Can approve when name is in approval process. Can function as a Search Committee member, with access to compile application material.

CSURSPUSearchChairII Search Committee Chair Plus Dynamic Query Role - CSU_SEC_CSURSPUSEARCHCHAIRLL
When name is associated with the Job Card as a Search Committee chair, has all functions of a Search Committee Chair I permission, but also has the ability to review applicants when assigned, can access applicant card, can create interview events, can communicate with assigned applicant, can view reference check responses and can view offer card with limited fields. Also has access to talent search.

CSURSPUSearchCommitteeI Search Committee Member
Name must be associated with the Job Card as a Search Committee member. Can review, and rank applicants, when name is added as a Search Committee member on the job card. Can view interview events if event function is turned on. This is the system default access if the User file does not bring over a permission in PeopleSoft, then user will be automatically assigned to this permission group.

CSURSPUSearchCommitteeII Search Committee with Compile Name must be associated with the Job Card as a Search Committee member. View only access to job card. Can review, and rank applicants, when name is added as a Search Committee member on the job card. Can compile selected application material into a PDF. Can view interview events if event function is turned on.

CSURSPUTApprover-Budget TApprover-Budget Same access as CSURSPUApprover-Budget for job card and applicant access. The difference is this permission will carry user's department access from PS into PU, so when running a report, the result can be from more than their own department.

CSURSPUTDeptAdminI Department Admin Limited Can initiate Job Card, and PD. Can approve if name is in approval process. Can edit job approval. Can create events. Can not bulk move applicants to different statuses. Can not initiate offer. Can not communicate with applicants. Can access applicant card, but no access to application material. Cannot revise job or PD after approval. Cannot access reference check. If named as search committee member, has same access as Search Committee Member with Compile function.

These roles are specifically intended for provisioning and deprovisioning access to the CHRS Reporting - QuickSight system, rather than granting PeopleSoft page access. The integration process for managing these roles will be handled by the CMS - Business Intelligence and Data Operations group.

The process will be scheduled to run daily at both noon and in the early AM hours. Its purpose is to ensure that user access to CHRS Reporting - QuickSight is up-to-date and aligned with the assigned roles and permissions.

Roles are provided as optional and should only be assigned to users when necessary.

In HCM 9.2, there are new configurations available to mask sensitive content on delivered PeopleSoft pages. However, custom CSU pages do not currently utilize this tool. Instead, they may have a custom solution in place to protect sensitive data fields.

The Sensitive data masking is limited to fields storing the following information:

• Bank Account Number
• Date of Birth
• National ID
• Driver’s License Number
• Passport Number

The Authorized Roles are configured for each field group, allowing users assigned with those roles to view the sensitive content associated with that field group. For all other users, the information is displayed as masked or hidden.

• Navigation
  • Set Up HCM > Security > Data Masking > Authorized Roles

Below is a list of Authorized Roles. Users who are authorized to access all sensitive data fields can be assigned the CHR_PT_Full_View_All role. Users who are authorized to view specific sensitive data fields can be assigned the corresponding role applicable to their access needs.

The example below illustrates the view of the DOB and SSN fields when a user is not authorized with a data masking role.

• Partial Masking of DOB – MM/DD – The year is not displayed
• Partial Masking of SSN – xxx-xx-1234 – Only the last four is shown
• Driver’s License - Number of unmasked digits 4
• Passport Number – Complete Value is hidden if user profile does not have authorized role
• Account Number – CSU does not store bank account number

• The list of roles below grant access to the PeopleSoft Query tool page. These roles enable users to utilize the PeopleSoft Query tool for retrieving and analyzing data within the system.
• Roles CHR_PT_Query_Manager and CHR_PT_Query_Private allow access to the Query Manager page.
• Navigation
  • Reporting Tools>Query>Query Manager
  • Only the CHR_PT_Query_Manager will allow users to save a query as ‘Public’.

Most users who only need to run predefined queries should be granted the role CHR_PT_Query_Viewer. This role provides access to the PeopleSoft Query tool specifically for running pre-existing queries. Users with this role can execute queries and view the results but do not have the ability to create or modify queries.

• Navigation
  • Reporting Tools>Query>Query Viewer

Users who have a business need to run or schedule queries should be granted the role CHR_PT_Query_Scheduler. This role provides access to the PeopleSoft Query tool, allowing users to not only run pre-existing queries but also schedule and manage query jobs.

• Navigation
  • Reporting Tools>Query>Schedule Query

Users who are granted access to the PeopleSoft Query tool will need one or more of the following roles listed below. These roles grant access to specific records, and users without these roles will not be able to view predefined queries or create new queries involving those records.

• Please note that roles containing "L1" in their name specifically allow access to records containing SSNs.

In HCM 9.2, the role named CHR_PT_IB_Support is available for campus Integration Broker monitoring purposes. This role is specifically designed for individuals at the campus who are responsible for monitoring and reporting any issues related to campus Integration Broker messages. By granting this role, users will gain access to the Service Operations Monitor, which facilitates monitoring and tracking of Integration Broker messages.

It's important to note that the Service Operations messages are not secured by campus. As a result, campus IB administrators will have view-only access to these messages. If they encounter any Integration Broker errors or issues, they should promptly report them by opening a ServiceNow ticket. The CMS team will investigate and work in coordination with the respective campus to resolve the reported issue. They will collaborate closely with the campus to identify the root cause of the problem and take appropriate actions to rectify it. Effective communication and collaboration between the CMS team and the campus are crucial to ensure a timely and satisfactory resolution to the issue at hand.

This role grants users the ability to enable Accessibility mode on the My Preferences page in HCM 9.2. By assigning this role, users will have the option to activate the Accessibility mode, which enhances the user interface to ensure better accessibility and usability for individuals with disabilities. This feature aims to provide an inclusive and user-friendly experience for all users within the HCM 9.2 system.

By assigning this role, users will be granted access to the Process Monitor page in HCM 9.2. The Process Monitor page allows users to view and monitor the status of various processes running within the system. Users with this role will have the ability to track the progress, success, or failure of specific processes and take appropriate actions as needed. Granting this role ensures that users have the necessary permissions to effectively manage and monitor processes within the HCM 9.2 system.

• Navigation
  • PeopleTools>Process Scheduler>Process Monitor

Users assigned with this role will have the capability to view jobs submitted by other user IDs on the Process Monitor page. However, access to the View Log/Trace feature will be limited to jobs that were submitted under their own user ID. This ensures that users can only review the log and trace details of the processes they initiated, maintaining data privacy and security. With this role, users can effectively monitor and manage their own job submissions while having visibility into the overall process status within the HCM 9.2 system.

Users assigned with this role will have access to the Report Manager page. This page allows users to manage and view reports generated within the HCM 9.2 system. The Report Manager page provides a centralized location for users to efficiently handle their reporting needs and access important information generated by the system.

• Navigation
  • Reporting Tools>Report Manager

The CSU FTP utility in HCM 9.2 includes three FTP roles. Two of these roles are reserved for the CO (Central Office), while the remaining role is designated for campuses. These roles grant authorized users the ability to securely upload files from within the HCM 9.2 application directly to the UNIX server. This functionality enables efficient file transfer and ensures proper data management within the system.

To grant access to the CSU FTP Utility, assign the role CHR_PT_FTP_Utility to the user. This role provides the necessary permissions and privileges to use the FTP utility within the HR 9.2 application. By assigning this role, users will be able to securely upload files to the UNIX server and perform FTP-related tasks as required.

• Navigation
  • CSU Tech Mods>FTP>FTP Utility

There are two roles available for granting access to component interfaces, web libraries, and web services in HCM 9.2. The role CHR_PT_PeopleSoft_User is required for all user profiles to access HCM 9.2. Additionally, administrative staff or power users who need to process or access advanced functionalities will require the role CHR_PT_PeopleSoft_Advance to be assigned to their user profiles. By assigning these roles, users will have the appropriate access and permissions to perform their tasks effectively within the HCM 9.2 system.

Please note that the role CHR_PT_PeopleSoft_Advance is a dynamic role, which means it can be manually assigned to user profiles as needed. For more detailed information on the assignment and management of dynamic roles, please refer to the CHRS Dynamic Roles document. This document provides comprehensive guidance and instructions on how to effectively handle dynamic roles within the HR 9.2 system.

These roles provide access to both PeopleSoft and CSU custom recruiting pages. It's important to note that these roles are distinct from the Recruiting roles that are prefixed with CSURSPU%. The CSURSPU% roles are specifically designed for granting access in PageUp and do not provide any page access within the PeopleSoft system. These roles below does grant access to PeopleSoft pages within HCM 9.2.

Campuses are encouraged to review and, if necessary, request the creation of campus-specific roles that allow for different combinations of Absence Management (AM) reports. The navigation to access the setup for Absence Report Access remains the same in both HCM 9.0 and HCM 9.2.

The ReportDistAdmin role is a standard PeopleSoft role, but we have added custom code to prevent campus users from viewing output from other campuses. Users with this role can view report output on the Process Monitor page for all users within their campus.

Please note that CO central support users who need to view reports for all campuses on the Process Monitor page must be assigned the 'CHRCO_ReportDistAdmin' role.

Each campus will have a role that they can assign to their campus superuser. This role doesn't grant page access in HR 9.2 but helps identify role members during upgrades or maintenance. A script will be used to lock or unlock users assigned to this role, allowing early access for system validation during upgrades. The role naming convention will start with "CHR," followed by the two-digit campus code, and then "_Super_User" (e.g., CHR50_Super_User).

Campus-specific roles are included in the CHRS baseline. These roles are prefixed with "CHR" followed by the two-letter campus abbreviation (e.g., CHRFL_%). These roles are designed for report distribution or workflow configuration.

A comprehensive list of module static roles for each campus can be accessed on SharePoint.

https://csyou.calstate.edu/groups/chrshome/areas/SitePages/Application%20Security.aspx (LINK NOT WORKING)

SWHR assigns several security roles that are campus-facing. These roles either grant access to system-wide data, QuickSight, or manage campus-distributed security administrators.

Only authorized users can submit requests. We use the existing CSU Technical User Group 'CHR, CFS & SEC' subgroup list (https://thecsu.sharepoint.com/sites/csutechnicalusergroup/Lists/TUG%20Contacts%20Information/AllItems.aspx) to determine who can access and submit the CHRS Security Access Request through the CSU Service Portal (https://csu.service-now.com/cosp?id=cospindex). Please coordinate with your campus TUG designee if additional individuals need authorization to submit the CHRS Security Access Request. Please note that by the time the online ServiceNow form is submitted, the required campus-level approval should already be completed. SWHR will then review and process the request in the system.

The T&L dynamic groups from HCM 9.0 were migrated to the new system. To ensure uniqueness and avoid duplicates, a two-letter campus prefix will be added to the group ID. Furthermore, an additional criteria of "AND JOB COMPANY (ex. = FUL)" will be included in the last line of the group definition. This criterion ensures that the dynamic group only includes data specific to the campus and avoids picking up information from other campuses in the consolidated database.

Please note that WORKGROUP (CSU_C_TL_WG_CW), EMPLID (csu_emplid_map), REPORTS_TO (csu_posn_map), and POSITION_NBR (csu_posn_map) values will be mapped to their HR 9.2 equivalents if your campus uses those fields in the Select Parameters of the Group IDs.

Static groups will not be converted or migrated to the HCM 9.2 system. Only dynamic groups will be established in HCM 9.2.

The two-character prefix was added to both the permission list and group ID. Additionally, the "Allow Prior Period Time entry" option was selected, and a value of 5 was set for the "Days Grace Allowed" parameter across all permission lists. It is important to note that campuses have the flexibility to modify these settings according to their specific business requirements.

Each TRC Program is mapped to one or more Time Reporting Codes(TRC’s) in the page below. The navigation to get to the Page is Set Up HCM > Product Related > Time and Labor > Time Reporting > TRC Program. The TRC Program is then mapped to a Workgroup and every Time Reporter is mapped to a Workgroup. This setup enables Time Reporters to pick a TRC while reporting time on the Employee Timesheet page(Navigation: Home page > CSU Time) and Manager Timesheet page (Navigation: Manager Self Service > Time Management > Report Time > Timesheet).

The TRC Access field is a drop down with 3 Options :

• No Restriction : When this option is selected for a TRC, a Time Reporter will be able to access the TRC on the CSU Time page and the Time sheet page which is accessible under the Manager Self Service Menu.
• Manager or Administrator Only: When this option is selected for a TRC, a Time Reporter will NOT be able to access the TRC on the CSU Time page. Only Managers and Time and Labor Adminsitartors will be able to access the TRC from the Timesheet page under Manager Self Service Menu.
• Administrator Only: When this option is selected for a TRC, a Time Reporter will NOT be able to access the TRC on the CSU Time page. Managers will also NOT be able to access the TRC from the Timesheet page under Manager Self Service Menu. Time and Labor Adminsitartors will be able to access the TRC from the Timesheet page under Manager Self Service Menu.

Managers and Time and Labor Administrators can report time for Employees using the Timesheets page under the Manager Self Service Menu (Navigation: Manager Self Service > Time Management > Report Time > Timesheet). Since both Managers and Time and Labor Administrators access the Timesheet page under the same navigation path, the way the system identifies if the User is a Manager or a Time and Labor Administrator is by checking the access the User ID has within the roles assigned to them.

• A manager is someone who only has access to the Menu : ROLE_MANAGER , Component : TL_MSS_EE_SRCH_PRD
• A Time and Labor Administrator is some who has access to the Menu : ROLE_MANAGER , Component : TL_MSS_EE_SRCH_PRD and also has access to the Menu : DEFINE_TIME_AND_LABOR , Component: TL_MSS_EE_SRCH_PRD
  • The current custom Security Role which provide access to CSU Time under the Employee Self Service option is CHR_TL_Timesheet_Employee. This role is assigned to Employees at CSU. This role grants access to TRCs marked as "No Restrictions" in the assigned TRC program's TRC Access field.
  • The current custom security Roles which provide access to Managers for reporting time for Employees reporting to them are: CHR_TL_Approver, CHR_TL_Timekeeper. These roles grants access to TRCs marked as "No Restrictions" or "Manager or Administrator Only" in the assigned TRC program's TRC Access field.
  • The current custom security Roles which provide access to Time and Labor Administrators for reporting time for Employees reporting to them are : CHR_TL_Payroll_Admin , CHR_TL_Central_Config. These roles grants access to TRCs marked as "No Restrictions", "Manager or Administrator Only", or "Administrator Only" in the assigned TRC program's TRC Access field.

During the security conversion process, the scripts will automatically add the value 'USA' to the Setup Global Security table for campus permission lists. However, for any new permission lists created by the campus, the 'USA' value will need to be manually added.

Set Up HCM>Security>Component and Page Security>Setup Global Security

During the security conversion process, the scripts will automatically add the default values to the Org Defaults by Permission Lst table for campus permission lists. However, for any new permission lists created by the campus, the campus administrators will need to manually set these values according to their specific requirements.

Set Up HCM>Foundation Tables>Organization>Org Defaults by Permission Lst