Campus will need to submit a ServiceNow request using the CHRS Security Access Request form. Only campus authorized requestors will be allowed to submit the request.

They will have to submit a CMS Data Center Campus Security Administrator “CSA” Application in order to gain access

Campuses will not have DS Oracle accounts in production.

No. CHRS development will be handled by the CMS central. Campus-specific modifications to CHRS are not allowed. Therefore, campus development access will not be authorized, unless it is granted to support a specific CHRS Program workstream activity.

Campuses will not have DU Oracle accounts in production.

When the specified rules are met, these roles will be automatically provisioned to users. Conversely, when the rules are no longer met, the roles will be deprovisioned from the users' profiles.

Dynamic role rules in CHRS are defined or coded using PeopleSoft Query, PeopleCode, or the Lightweight Directory Access Protocol (LDAP) directory. We have specifically chosen to utilize the Query Rule Enabled and PeopleCode Rule Enabled (Recruiting Only) feature for several security roles in CHRS. 

The application engine program DYNROLE_PUBL is responsible for assigning dynamic roles based on the query logic that retrieves a list of operator IDs. The DYNROLE_PUBL batch job will be centrally managed by CMS and scheduled to run hourly from 4 am to 8 pm, Monday to Friday.

To view the dynamic roles assigned to a user, you can navigate to the user profile page and access the roles tab, where they will be displayed along with other roles.

Yes, you can find a complete list of the Dynamic Roles in the CHRS Library, located under the Security Tile.

A complete list of the Dynamic Roles can be found in the CHRS Library, located under the Security Tile.

A complete list of the roles can be found in the CHRS Library, located under the Security Tile.

A complete list of the roles can be found in the CHRS Library, located under the Security Tile.

Security Roles and Permissions lists for CHRS are defined and maintained by the CHRS Security Team. A systemwide set of security roles and permission lists will support approved job functions required to implement the CHRS business practices defined and approved by Systemwide HR.

Yes, campuses will have the ability to assign roles to users based on the job function(s).

Campuses will not be able to create or modify roles in either production or non-production environments. While campuses can create permission lists to define row-level security, they will not be able to add components to campus-specific permission lists.

No. Campuses can submit a request (ServiceNow Ticket) to the Central Security Office to implement those changes in PRD, supplying the required specific business need/function this addresses. The request will be reviewed by the CHRS Security Team, CMS Module Teams and approved by the Systemwide HR for inclusion in CHRS.

Yes. Campuses can submit a request (ServiceNow Ticket) to the Central Security Office to implement those changes in PRD, supplying the required specific business need/function this addresses. The request will be reviewed by the CHRS Security Team, CMS Module Teams and approved by the Systemwide HR for inclusion in CHRS.

Run the following PeopleSoft query: CSU_SEC_FIND_ROLE. The query will ask for you to Enter Page Name and then provide you with the associated role. 

Campus users will not have a role that allows them to modify the NavBar. 

For CHRS, security will be in place so that users will not be able to add or remove from the NavBar.

For CHRS, security will be in place so that users will not be able to add or remove from the NavBar.

No, authorized user will need to one or more of the following security roles:

• CHR_PT_Full_View_All
• CHR_PT_Full_View_DOB
• CHR_PT_Full_View_Driver_Lic
• CHR_PT_Full_View_Passport_Nbr
• CHR_PT_Full_View_SSN

In CHRS, the following fields will be masked (redacted): DOB, SSN, Driver License, and passport number.

Campuses can tell that a role is for CO only based by the short and long description. The description will have "COO" and the Long Description will have a note that it's CO Only.

No, the campus Hierarchy and Department Security trees will be converted as part of the conversion process.  No additional changes are necessary for them.  It is recommended to run the Oracle delivered tree auditor in in their 9.0 production environment and take action as needed.

 Yes, users with access to the Process Monitor page can view jobs submitted by others, but they won't be able to access the results unless they have additional permissions.

Campuses can access only campus-specific submitted jobs, and only if the 'ReportDistAdmin' role is assigned to their user profile.

No, users will only see output in their Report Manager page if they submitted the job themselves or were added to the job’s distribution by another user.

The campuses will need to submit a ServiceNow ticket requesting a password reset.

No. All individuals in CHRS are required to have a User Profile, regardless of their status, and campuses will not have the ability to delete these profiles.

In CHRS, there are various types of duplicates, each requiring a different approach for resolution. Campuses should consult the Managing Duplicates document found in the Integration section of the CHRS Knowledge Base.