FINANCE and HR Systems Access Guidance Document (Updated November 2013)
Access requests for Finance, HR and CIW Systems are controlled at the campus level by the campus security
coordinators. The campus security coordinator must verify that an access request is appropriate and that all
requirements for access have been fulfilled in accordance with the guidelines presented in this document. As of
August 1, 2012, campus FIN security coordinators are also provisioning the access requests (with some
limitations), by granting roles in accordance with the guidelines presented in the Finance System Provisioning
Handbook. Permissions and restrictions for FIN role granting are detailed in the FIN Distributed User Role Grant
Mapping document (Exhibit VII).
HRMS and CIW access, any restricted FIN access and all requests for discontinued access will continue to be
handled by the Access Management Provisioning Team (AMPS) with University Information Systems (UIS).
FIN and HRMS campus security coordinator contact information can be found in Exhibit I of this document; a
quick link is below:
https://www.cu.edu/ums/security/CUonly/AMPS/coor.php
AMPS also maintains a website containing access guidance information, links to access request forms, and
current lists of campus security coordinators. The AMPS website is located at:
https://www.cu.edu/ums/security/CUonly/AMPS/index.php
All records of operator information, including access requests and any subsequent revisions in user access, will
be documented and maintained in the Singularity document database maintained by UIS. UIS will be responsible
for generating reports as set forth in these guidelines, or at the request of the campus security coordinators, for
purposes of periodic system access review. As a general rule, these access reviews will be initiated and
conducted by the campus security coordinators.
I. STANDARD SYSTEM ACCESS PROCESS
A.
Access Request Forms – General Information
AMPS maintains links to all access request forms (with the exception of some HR forms administered
through Employee Services) on their website. Most forms are electronic and use electronic signature and
routing applications, allowing for prompt delivery through email. Access request forms may also be
scanned and sent as email attachments, or submitted through SupportWorks (with a scanned copy of the
signed access request form).
Requestors complete the required system access request form, obtain supervisor approval and send the
completed and signed forms to the appropriate campus security coordinator.* Forms are available on the
AMPS website at:
https://www.cu.edu/UMS/security/CUonly/AMPS/accessrequestforms.php Forms include:
 Finance System/Marketplace Access Request
 Developer Account Request*
 HRMS System Access Request
 HRMS Specialized Access
 HRMS Compensating Controls Certification
 HRMS Tree Change Request
 CIW Access Request
 Discontinue Access Request
* Developer Access Request forms are administered through Access Management, but require additional
approvals. FIN Developer Access Requests require approval from the Director of Financial Reporting
Systems and the Director of Application Development. HRMS Developer Access Request Forms must
also be approved by the Director of Application Development.
1
B.
Access Request Review Process
As noted earlier, requests for access to FIN, HRMS and/or CIW systems are initiated by the individual
operator and his/her supervisor. Both the operator and supervisor must sign the request form and
forward that to the appropriate campus security coordinator. Campus security coordinators review
requests and complete the following steps:
1) Check for existing User ID - Does the individual requesting access already have a PeopleSoft User
ID? Under the current single sign-on system, all employees are assigned a unique User ID allowing them
access to the enterprise portal and PeopleSoft systems. These IDs are formatted with the first four letters
of the user’s last name, followed by a six-digit number. User IDs attached to one individual cannot be
reused for another individual. On occasion, a secondary user ID may be required for some employees
with special job duties. Clarification may be needed from the operator/supervisor as to which of the IDs
should be used for the access request submitted.

Instructions for checking existing PeopleSoft Operator IDs are contained in Exhibit II of this
document and in the Provisioning Handbook.
2) Verify training completion - Training is required before access to PeopleSoft systems can be
granted. In all cases, the general IT Security training (Course # U00063 - Information Security and
Privacy, available through SkillSoft) must be completed before access can be granted. A more detailed
listing of training required for specific FIN and HR roles is included in Exhibits IV and V. Training
requirements for specific roles are also noted on the FIN and HR access request forms.
Campus security coordinators must verify that all required on-line and classroom training has been
completed. If all training is not completed, but FIN access is required immediately, please refer to section
I-C (below) for provisions for granting temporary access in FIN. Please note that all required training
must be completed in order to receive HRMS and CU Marketplace access; there are no provisions
for temporary access for HRMS or CU Marketplace roles.
Instructions for verifying training can be found in Exhibit III of this document.
3) After training has been verified, review and qualify the request:

Are special approvals required (see Section IA)? If so, have they been obtained?

Is Incompatible Access being requested (check new roles requested against existing roles, if
applicable)? If so, review Section II below for guidance.

Is the access requested appropriate for the user? For example, does the person need to see
personal information as part of his or her job duties? Does the person need to see information from all
campuses/org units? Can the user get what he or she needs from CIW without opening access to
critical financial tables? Does the person have the appropriate row level security to be given access
to certain HRMS roles? If a secondary user ID is being requested, has sufficient justification for the
secondary ID been provided?

Does the user have multiple PeopleSoft IDs? If so, please ensure that the access requested is
assigned to the correct ID.
2

Campus Specific Qualification Guidelines (UCCS):
Ensure that UCCS departments are not requesting Cash Transfer Journal Entry or Cash
Transfer Approval roles as well as Budget Journal Approval. Personnel in the Resource
Management Division are the only personnel who may have these roles.

Campus Specific Qualification Guidelines (UCD):
Ensure that UCD departments are not requesting Journal Entry (JE) Approval roles for
their employees (JE Actuals Approval and JE Cash Transfer Approval). These JE
Approval roles cannot be granted to anyone outside of the Finance and Grants and
Contracts area.

Campus Specific Guidelines (UCB)
1) Ensure that UCB departmental users (excluding Accounting and Business Support
{ABS} users and several assistant to the VC users) are not requesting both create and
approve JE and/or Cash Transfer roles. UCB Finance System users are not allowed to
have both create and approve JE or Cash Transfer roles.
2) Ensure that UCB departmental users are not requesting the Approve Budget Journals
role. This role is limited to staff in the office of Planning, Budget and Analysis (PBA).
3) Since the Dean’s office of the College of Arts & Sciences maintains a budget upload
process, ensure that individual Arts & Sciences users are not requesting the JE-Budget
create role.
4) Submitting the Request
Access request forms are designed to logically move from one approver to the next, using electronic
routing buttons on the form. Scanned copies of signed FIN access request forms can be submitted to the
security coordinators as email attachments by sending them to appropriate campus finance coordinator
(see https://www.cu.edu/ums/security/CUonly/AMPS/coor.php for FIN access coordinator contact info ),
or they can be submitted as attachments to Supportworks tickets. If a form is submitted out of sequence,
i.e., before all required signatures have been obtained, the form will be returned to the individual who
submitted it, along with an explanation of proper routing procedures. Email requests for access may also
be accepted, at the discretion of the campus security coordinator, so long as they have the approval of
the employee’s supervisor.
Once the campus security coordinator has reviewed and approved the request, the roles can be
provisioned, either by AMPS or by the FIN security coordinators, as appropriate.
Once all signatures are obtained, HR access request forms can be submitted electronically using the
routing buttons on the new form, or they can be scanned and submitted to access@cu.edu , or via a
Supportworks ticket as noted above.
3
Request Flow
Operator Signature
Supervisor Signature
Security Coordinator Signature*
AMPS
* Depending on the access requested, additional signatures may be required before or after the access
coordinator’s signature (e.g., Incompatible Access requests require an Incompatible Access reviewer
signature before routing to the security coordinator; University Controller signature for “All Funds” access
requests, and director signature(s) for developer access requests are required prior to routing to AMPS.
5) Processing the Request – FIN Security Coordinators
As of August 1, 2012, FIN security coordinators are authorized to provision access requests (with some
limitations). Assuming that all signatures are in order, and all required training has been completed (or
temporary access is permissible), FIN security coordinators may provision the access request by making
the appropriate entries in the Finance System. Upon completion of the provisioning request, the user and
his/her supervisor are notified via email, and all correspondence, including a copy of the signed access
request form, is documented in the Singularity document management database.
6) Processing the Request – Access Management
Upon receipt of the access request form, Access Management will check signatures, and then send an
email acknowledgement to the user, supervisor and campus security coordinator confirming that the
request has been received.
Access Management will then provision the request by making the appropriate entries in the PeopleSoft
systems. When processing is complete, Access Management will send an email to the operator,
supervisor, and campus security coordinator confirming that the access request has been finalized. All
correspondence, including a copy of the signed access request form, is documented in the Singularity
document management database.
C.
Temporary Access
Because classroom-based training is required for some FIN roles, and because that training is not always
readily available, it may be necessary to grant user access on a temporary basis, until all classroom
training can be completed. If all required online training courses have been completed, campus security
coordinators and AMPS may, at their discretion, grant temporary (90-day) FIN access to an operator.
Temporary access cannot be granted for CU Marketplace or for any HRMS roles.
4
Campus security coordinators should note on the FIN access request form that access is “Temporary.”
Campus security coordinators should maintain records of these temporary access situations and followup as outlined below:
1) Campus security coordinators will track all FIN temporary access requests to ensure that all required
training is completed within 90 days. Reminder emails should be sent to the user and his/her
supervisor at 30 and 60 days, with a final notice at 90 days. Temporary Access must be terminated
within three business days of this final notice.
2) If the required training is not completed, the campus security coordinators will notify AMPS and
request that the operator’s FIN access be terminated no later than three days after the final notice is
sent. If the campus security coordinator determines that there are extenuating circumstances that
may justify continuation of access for another 60 days (e.g., required training has not been offered,
personal hardship, etc.), campus security coordinators must document those circumstances and
maintain those records.
3) Campus security coordinators must send an email notification to the user and the Supervisor/Sponsor
notifying them when the user’s FIN access is discontinued.
II.
A.
INCOMPATIBLE ACCESS
Definition – Incompatible Access (IA) occurs when employees have roles that allow them
access that bypasses the normal segregation of duties (e.g., both create and
approve roles for journal entries, CU Marketplace requestor and approver, etc.). Ideally, granting
this type of access should be limited or avoided altogether; however, in some cases, incompatible
access roles may be necessary to conduct business (e.g., departments having a limited number of
personnel).
Currently the following role-pairs constitute Incompatible Access in FIN:









JE Actual + Approve Journals
JE Budget and JE Budgetinit + Approve Budget Journals
JE Encumbrance + Approve Encumbrance
JE Transfer + Approve Transfer
Purchase Order (PO) + Approve PO*
ePro Requestor + ePro Approver IA (CU Marketplace)
ePro Shopper + ePro Inquiry and/or ePro Requestor (CU Marketplace)
Requisitions + Approve Requisitions*
AP Manager + Approve PO, Approve Purchasing, Apprv SPO Voucher, Procurement
Manager, PurchAgent, Purchasing Manager and/or Vendor Manager
* Functions are no longer active entry roles; recorded for historical purposes only.
Currently, the following role-pairs constitute Incompatible Access in HRMS:





Time Collection and Time Entry Approval Roles
Payroll Personnel Liaison/Time Entry Approval
Payroll Personnel Liaison/Job Data Hiring Approval
Payroll Personnel Liaison/One-time Payment Approval
Campus HR Role
Please note that other University systems contain role pairings that may give operators incompatible
access, such as MyLeave (supervisors who have the ability to both create & approve employee
timesheets and Payroll Personnel Liaisons (PPLs) who can also approve timesheets). While this access
is not directly controlled by AMPS or the campus security coordinators, everyone should be mindful of this
when reviewing and granting access in PeopleSoft.
5
B.
Granting Incompatible Access
If someone has requested Incompatible Access, then the campus security coordinator
will:
1) Review the request to determine that the justification for the Incompatible Access request is
legitimate.
2) Ensure that an appropriate compensating control has been identified on the access request form.
3) Make sure an Incompatible Access Reviewer has been identified, and verify that the Reviewer is an
Active Employee. It is strongly recommended that the reviewer is either the supervisor or sponsor of
the employee requesting access, or someone else in a position to challenge the appropriateness of
transactions performed using Incompatible Access.

Campus Specific Guidelines (UCD):
The campus security coordinator must notify the appropriate campus personnel so they are
aware of new Incompatible Access requests. If within a department, ensure that the
Department Fiscal Manager is approving the request even if he or she is not the Reviewer. The
Denver campus is (1) working to reduce the number of Faculty performing the Reviewer
function and (2) trying to work with departments to adjust access profiles for the purpose of
eliminating IA.
4) Campus security coordinator approves and sends request to Access Management, or completes the
provisioning process by granting the requested roles.
5) When Incompatible Access has been granted, Access Management or the FIN security coordinator
will enter the person’s information in the Incompatible Access panel in FIN with the effective date and
the Reviewer’s information. HRMS does not have this panel for recording IA users and reviewers,
although a method for systematically storing this information will be explored for future modules.
Accordingly, information on HRMS Incompatible Access operators and reviewers is maintained and
monitored by the campus security coordinators.
6)
C.
The access request form (including the Compensating Control section) is documented and
maintained in the Singularity document database. HR security coordinators maintain the
Compensating Control section of the form for HRMS Incompatible Access users.
Incompatible Access – Basic Follow-up and Review
Security coordinators monitor users with Incompatible Access by making sure that IA operators and
reviewers are logged, either in the Finance System (for FIN IA operators) or in manually maintained
spreadsheets (for HRMS IA operators). Security coordinators for both FIN and HRMS should reconcile
their records of IA operators monthly against the Operators with Incompatible Access report available in
the Access Management folder in the Reporting System. Any variances between the Access
Management report and security coordinator records should be investigated and information should be
updated as needed. Additionally, campus security coordinators should review their IA operator and
reviewer population for any changes in employment status (e.g., termination, transfer, position changes),
using reports provided by AMPS and the Office of University Controller.
The Transferred Employee Report, also available in the Access Management folder in the Reporting
System, should be reviewed on a monthly basis so security coordinators can identify operators with
HRMS or FIN system access who have changed positions or transferred to another department or
campus. Campus security coordinators must make contact with those employees and/or their supervisors
to determine if Incompatible Access is still required. If IA is still required, a new Incompatible Access
6
reviewer should be identified. The FIN security coordinator is responsible for updating the Incompatible
Access table in the Finance System when a user’s roles change and Incompatible Access is no longer
required.
The Terminated Operators on the Finance System Incompatible Access Table and Invalid Reviewers on
the Finance System Incompatible Access Table reports are distributed monthly to FIN System security
coordinators, and are generated and maintained by the OUC based on IA operator and reviewer
information stored in the Finance System. Security coordinators should notify AMPS when a FIN
Incompatible Access operator has retired or terminated so that the incompatible access Operator ID can
be deactivated.*
*Note: The checkbox for Incompatible Access in FIN must remain checked when a terminated
user’s ID has been deactivated. For active employees whose IA roles are removed from their user
profiles, a new tab should be created on the Incompatible Access page with the checkbox cleared.
If an Incompatible Access reviewer has retired, terminated or transferred, campus security coordinators
must confirm that any IA operators who were reviewed by this individual have been assigned to a new
reviewer.
All changes must be documented; if a new Incompatible Access Reviewer is being named or if a new
Compensating Control method is being selected, the campus security coordinator must obtain and review
an updated Compensating Control form, and either pass it on to Access Management for processing, or
update the IA reviewer information in FIN or in any manually maintained Incompatible Access records. As
with all other access information, any new documentation must be entered into the Singularity document
database.
D.
FIN System Incompatible Access Reviewer Responsibilities
Employees who have been designated as reviewers of users with Finance System Incompatible
Access must conduct regular reviews (on at least a quarterly basis) of the IA activity of their IA
operators. To accommodate this review, reports of FIN Incompatible Access activity are available
to designated reviewers in the Cognos reporting system.* Review activity should be documented
and maintained so as to be readily available for any audit requests. It is primarily the IA reviewer’s
responsibility to take appropriate corrective actions when there is evidence that incompatible
access is being used improperly.
*Note – Review processes for Procurement transactions are detailed in the Compensating Controls
section of the FIN System Specialized Access Request Forms.
E.
HRMS System Incompatible Access Review Responsibilities
HRMS security coordinators are responsible for providing reporting on the Incompatible Access activity of
IA operators to the appropriate reviewers. Coordinators use two PeopleSoft Auditing reports - ‘Personnel
Actions Audit’ and ‘Time Entry Audit’ - to monitor IA activity in HRMS. When IA operator activity is noted
in a reporting period, the HRMS security coordinator must deliver (email) the reports of this activity to the
IA operator’s reviewer of record if that reviewer does not have access to HRMS to run those reports. This
review process is conducted on at least a quarterly basis.

Campus Specific Guidelines (UCB):
The UCB HRMS security coordinator will run the incompatible access review reports for all
reviewers of HRMS Incompatible Access.
F.
Annual Incompatible Access Recertification Process
7
On an annual basis, the campus security coordinators will administer a process to ensure (1) that
those who have Incompatible Access still need it and (2) that the Incompatible Access Reviewer
information maintained in the Finance System (or manually, in the case of HRMS security
coordinators) is accurate. The Incompatible Access Certification process for FIN is scheduled by
campus and is recorded in the Finance System under Setup Financials/Supply Chain – Security –
Campus Email Schedule. Campus security coordinators should set an annual calendar reminder
of the Incompatible Access recertification dates so that timely follow-up can be maintained.
HRMS security coordinators manually maintain records on Operators with Incompatible Access,
and schedule annual reviews for recertification.
The Incompatible Access recertification process works as follows:

The OUC sends email notifications to operators with FIN Incompatible Access. This notice is
automatically generated based on campus schedules established in the Finance System. HR IA
operators receive a manually generated notice, based on an established annual review process.

Incompatible Access operators receiving these emails must then forward the email to their designated
reviewers.

Reviewers of the IA operators must certify, in an email to the appropriate campus security
coordinator, that the Incompatible Access roles for the operator in question are still necessary, and
that the previously identified Compensating Control is in place and is being used for review purposes.

Security coordinators must follow for receipt of email confirmations from the appropriate reviewers,
using information from the most recent Operators with Incompatible Access reports supplied by
AMPS.

Security coordinators must review responses and communicate to Access Management (or record in
FIN) any necessary changes in Incompatible Access roles, reviewers or review processes.

If reviewer information has changed, the security coordinator should update the reviewer information
in FIN (for FIN users) or in the manual records maintained by the HR security coordinators (for HR
users).
If there is no confirmation after thirty days, campus security coordinators will:

Actively investigate any situations where Incompatible Access has not been confirmed. Incompatible
Access may be continued for those operators during the course of the investigation.

Take actions appropriate to the results of these investigations.
If, after 10 more days, there is still no confirmation, campus security coordinators will:

Send email notification to the IA Operator and his/her reviewer that access will be terminated in three
business days unless reviewer confirmation is received.

Follow through by requesting that Access Management terminate any incompatible roles for the
Operators in question at the end of the three-day waiting period.
Security coordinators must maintain a record of follow-up performed for the annual Incompatible
Access certification process, including documentation supporting any changes made to IA roles,
reviewers or compensating controls.
III.
PERSON OF INTEREST (POI)
8
A.
Definition - POIs are typically individuals who are not directly employed by the University,
but are employed by a University affiliate.* These individuals may be performing University-related
research or conducting other University business, and may require access to University systems
(FIN, HRMS, CIW) in order to fulfill their job duties. POIs may be granted access to University
systems under the following conditions:

A designated University employee must act as a sponsor for the POI.

The POI must be set up in HRMS as having “Type 15 – Security Access.” (See Exhibit VI for
instructions on checking POI access coding, sponsor information, system end dates, etc.).

The appropriate access request forms are completed and submitted with all required approvals to the
campus security coordinators and/or Access Management.

All required training is completed.
* Note: In rare cases, active University employees may be set up as POIs in order to be granted
to systems on another campus (e.g., internal audit personnel).
access
Campus security coordinators will verify that:
B.

The POI has been set up with Type 15 – Security Access (based on the information in the POI setup
screens in HRMS). The process for verifying POI access is outlined in Exhibit VI.

A valid sponsor/supervisor is listed for the POI on the access request form (must be an active
University employee).

If the POI is requesting Incompatible Access, he/she must be from an affiliate that has a signed
agreement with the University or from an affiliate that has a signed Federal & State Work/Study
Agreement in place.

These individuals must be coded as a VIP-POI in HRMS. One person on each campus has access
to code POIs as VIP-POIs. VIP-POI is indicated by a check in the box “Fiscal Relationship” (as of
November, 2011, only Children’s Hospital has this VIP status).

A valid reviewer (must be an active University Employee) is listed.

A valid Compensating Control is identified.
POI Review Process
Security coordinators should review reporting on their campus POIs on a regular basis. A collection of
POI exception reports (POIs expiring within 10 days, 30-60 days, and POIs with system access who are
not set up as Type 15) is available in the AMPS folder in the Reporting System. Another report distributed
on a regular basis identifies POI sponsors who are no longer active in HRMS. Security coordinators
should review these reports on a monthly basis, and use these reports for comparison purposes during
the ongoing POI recertification process outlined below.
POIs with access to Finance, HRMS and CIW systems must certify as to the appropriateness of their
system access on an annual basis.
C.
POI Recertification – Ongoing Certification Process
Effective October 1, 2013, the ongoing POI certification process will be as follows:
9
IV.

Information Resource Management (IRM) will run a monthly report identifying POIs with
access to FIN, HRMS and/or the CIW whose end dates (whether current year or futuredated) occur during that month. This report, the POI Notification report, will be available
to the security coordinators in the POI Notification folder under the Access Management
Reports. IRM will also send email notifications to those POIs and their sponsors advising
them that POI recertification is required. Sponsors will be asked to confirm that the POI
in question remains active and still requires access to the FIN, HRMS and/or CIW
systems. Sponsors will also be asked to ensure that the POI maintenance screens in
HRMS are updated to reflect an accurate end date.

Sponsors will be asked to certify to poi_notification@cu.edu; this directory includes all of
the campus security coordinator email addresses (e.g., finance.access@colorado.edu).

Campus security coordinators will have 30 days to follow on the required certifications
(using the report in the Access Management folder) and ensure that all steps necessary
for certification have been completed (including updated POI end dates).

Campus security coordinators are responsible for sending requests to discontinue access
for all POIs who have not certified by the first business day of the following month
(unless the security coordinator determines that additional time is needed for the
certification).
TERMINATED/RETIRED OPERATORS
Reports of terminated employees with system access are sent to the security coordinators on a weekly
basis. These reports are also available at any time in the Access Management Reports in Cognos.
Unless security coordinators respond otherwise, access for terminated employees will be discontinued
automatically by the Access Management team. Additionally, a report listing terminated employees with
system access is available in the Access Management folder in the Reporting System. Security
coordinators should review all reports to confirm that access for terminated employees is discontinued in
a timely fashion.
Under no circumstances will a terminated employee's ID remain active or be reactivated until the
employee’s HR status reflects that the employee is active.
V.
TRANSFERRED EMPLOYEES
This report (available in the Access Management Reports folder) is designed to identify
employees who have changes in position number and/or department number within the
University. Security coordinators should institute follow-up on this report to determine
whether the existing FIN, HRMS, and/or CIW access for the transferred employees
continues to be valid.

On a monthly basis, security coordinators should review this report to identify transferred employees
for whom updated FIN, HRMS, or CIW access requests have not been received/updated.

If there has been no recent request for updated access, the security coordinators should contact the
employee’s current supervisor to confirm whether existing FIN, HR and/or CIW roles are still valid; if
not, an updated access request form, signed by the new supervisor, should be requested. For
reference purposes, security coordinators should provide the new supervisor with a listing of roles
currently assigned to the transferred employee.
10
VI.

Security coordinators will be responsible for tracking responses to these emails and ensuring that the
transferred employee’s access is updated as needed.

Security coordinators should request termination of access for all those transferred employees for
whom confirmation cannot be obtained.
INACTIVE OPERATOR IDS
Enterprise portal passwords expire every 90 - 180 days (depending on the campus) and
must be reset using a University computer or through authorized VPN access. It is felt that
this practice, in conjunction with the weekly review of terminated operators and the ongoing
POI certification process, is sufficient to mitigate any risk associated with inactive IDs.
VII.
PROCESS FOR CHANGING PERMISSIONS AND ROLES
Permission and role changes should be done using an access request form, a Supportworks
ticket, or by email authorization (from a supervisor). As with any access request, campus
security coordinators should review the permission and role change requests to determine
1) that they are appropriate, 2) that all required training has been completed, and 3)
whether an Incompatible Access situation has been created. All requests for Incompatible
Access should be handled in accordance with Section II above. All permission and role
change requests should be documented and maintained in the Singularity system.
VIII. ACCESS DISCONTINUATION
Access can be terminated or revoked by submitting the Discontinue Access Request Form,
by submitting a SupportWorks ticket, or by sending an email authorization. The first two
methods are preferable to email notifications, but all are accepted by Access Management.
Any revision or discontinue access request should be documented and maintained in the
Singularity document database.
IX.
RECORD RETENTION
University record retention policy revised as of December 2007 called for a retention period
of three years for access authorizations or revisions. Access Management has historically
maintained those records, which are being converted to the Singularity document database.
With changes in the FIN provisioning process, FIN security coordinators must be mindful
that all access requests and revisions need to be documented and maintained in the
Singularity system.
11
EXHIBIT I
Link to all campus security coordinator contact info:
https://www.cu.edu/ums/security/CUonly/AMPS/coor.php
HRMS Coordinator Group Emails:
hrmsaccess@ucdenver.edu (UCD);
hraccess@colorado.edu (UCB);
hrms@uccs.edu (UCCS);
systemshrms@cu.edu (System).
FIN Coordinator Group Emails:
finance.access@ucdenver.edu (UCD);
finance.access@colorado.edu (UCB);
uccsfin@uccs.edu (UCCS)
controller@cu.edu (System).
12
Exhibit II

Search for existing User IDs and roles in FIN and/or HRMS using the following navigation:
NAVIGATION: People Tools > Security > User Profiles
Do a basic search by User ID or an advanced search by description (user’s last name, first name - case
sensitive). Each User ID begins with the first four letters of the operator’s last name, followed by a 6-digit
number. Users may have multiple IDs to accommodate their work needs; if so, the secondary ID will be
in the old format, beginning with a letter of the alphabet designating the user’s campus (B = UCB; C=
UCCS;, D, H, and U = UCD; R = System), followed by a five-digit number.
Campus security coordinators may also use the reports generated by Access Management (Operator
Access FIN Systems, Operator Access HR Systems, or the new Access to Systems report) to check for
active User IDs and roles in FIN, HRMS, CIW or ISIS.

Click the ‘Roles’ tab to view existing roles in FIN and HRMS
13
Exhibit III
Training Verification

Training can be verified in HRMS as follows:
NAVIGATION: Enterprise Learning > Result Tracking > Review Training Summary
1) Enter the individual’s EMPLID or name.
2) Click ‘Search’ – A listing of completed course codes and titles will appear, along with grades (if
applicable) – see below:
14
EXHIBIT IV
HRMS System Security and Related Training Requirements
Below is a summary of the types of HR System access and the corresponding required training
courses. These courses must be completed with passing grades in order to obtain permanent security
to the HRMS system.
If requesting HRMS Inquiry only:
Course Title
HRMS-Fundamentals
HRMS-Inquire/Reporting
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
Course Number
A00029
A00030
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
SkillSoft
If requesting HRMS Time Collection Entry:
Course Title
HRMS-Fundamentals
HRMS-Inquire/Reporting
HRMS-Time Collection
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
Course Number
A00029
A00030
A00031
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
SkillSoft
SkillSoft
Course Number
A00029
A00030
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
SkillSoft
If requesting HRMS PET Entry only:
Course Title
HRMS-Fundamentals
HRMS-Inquire/Reporting
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
If requesting HRMS Payroll Personnel Liaison:
Course Title
HRMS-Fundamentals
HRMS-Inquire/Reporting
HRMS-Time Collection
HRMS Functional Training
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
Course Number
A00029
A00030
A00031
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
Instructor Led
SkillSoft
SkillSoft
15
If requesting HRMS Approval:
Course Title
HRMS-Fundamentals
HRMS-Inquire/Reporting
HRMS-Time Collection
HRMS Functional Training
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
Course Number
A00029
A00030
A00031
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
Instructor Led
SkillSoft
SkillSoft
16
EXHIBIT V
Finance System Security and Related Training Requirements
Below is a summary of the types of Finance System access and the corresponding required training
courses. These courses must be completed with passing grades in order to obtain permanent security
to the financial system.
If requesting Financial Inquiry only:
Required
Course Title
Financial – Inquiry *
Fiscal Code of Ethics Training
Information Security and Privacy
Awareness
Course Number
A00105-0001
F00001-0001
U00063
Type of Course
SkillSoft
SkillSoft
SkillSoft
Optional (encouraged but not required)
In person Financial Inquiry Training
* The Financial-Inquiry training requirement may be waived for employees needing access to FIN
primarily for user maintenance purposes (e.g., UIS personnel).
If requesting Financial Journal Entry capability:
Required
Course Title
Financial – Inquiry
Fiscal Code of Ethics Training
Information Security and Privacy
Financial – General Ledger
Financial – Inquiry
Financial – General Ledger
Course Number
A00105
F00001
U00063
A00106
A00101
A00102
Type of Course
SkillSoft
SkillSoft
SkillSoft
SkillSoft
In Person
In Person
PowerPoint – OUC
Gift Management Training*
F00004
website
Gift Fund Mgmt – Beginner – Web**
U00082
SkillSoft
* Required training for anyone holding a fiscal role on Gift Fund SpeedTypes (Fund 34); this training
was replaced by Gift Fund Mgmt-Beginner-Web (U00082) as of November 1, 2011.
** Required basic gift fund training as of November 1, 2011.
17
If requesting CU Marketplace Access (e-Procurement roles):
Shopper –only training:
Course Title
Information Security and Privacy
Awareness (required)
CU Marketplace - Shopper (optional)
Course Number
U00063
Type of Course
SkillSoft
U00080
SkillSoft
Basic Training Requirements – All Other CU Marketplace roles:
Course Title
Fiscal Code of Ethics Training, or
Fiscal Code of Ethics - Officers (for Officers only)
Information Security and Privacy Awareness
Procurement – Purchasing and Contract Management
Course
Number
F00001
F00002
U00063
A00109
Type of
Course
SkillSoft
SkillSoft
SkillSoft
SkillSoft
Course
Number
A00146
U00084
Type of
Course
In person
SkillSoft
Course
Number
A00147
U00081
Type of
Course
In person
SkillSoft
Course
Number
U00090
Type of
Course
SkillSoft
Course
Number
U00091
Type of
Course
SkillSoft
Role-Specific CU Marketplace training requirements:
Requestor
Course Title
CU Marketplace Requestor, or
CU Marketplace Requestor - Web
Approver
Course Title
CU Marketplace Approver, or
CU Marketplace Approver - Web
Receiver
Course Title
CU Marketplace Requestor - Web
Invoice Approver
Course Title
CU Marketplace Invoice/Match Exception Approver - Web
18
EXHIBIT VI
POI Information Screens
POIs are not employees of the University and do not have job records or position information recorded in
HRMS. However, biographical information and job assignment information can be located under
“Personal Information” in HRMS.
To look up a POI, log into HRMS and navigate as follows:
1) Workforce Administration > Personal Information > Organizational Relationship > Maintain a Person’s
POI Reltn.
2) Under the Maintain POI Types screen, enter your search criteria (name or POI ID #).
19
3) Upon entering the info, you will see a screen that looks like this (below); please note that an employee
may be set up as more than one POI type (Type 15 setup is required for systems access):
4) Click on any of the links on the results page to see more information on this POI (sponsor info, end
date, etc.). When in production mode, changes can be made on this screen to update POI information.
20
5) If you have difficulty identifying a POI by number or name, you can search using the “Search for
Matching Persons” function, or “Modify a Person.”
To use “Search for Matching Persons, navigate as follows: Workforce Administration > Personal
Information > Search for Matching Persons. Please note that this screen is case sensitive – first last and
middle names must be capitalized. Once search criteria is entered, click on the “Search” button at the
top right of the screen; hitting enter will not produce any search results.
21
Example – Search for Matching Person
6) To search for a POI using “Modify a Person,” navigate as follows: Workforce Administration >
Personal Information > Modify a Person
22
Example – Modify a Person
7) Search results using either of these functions will return the ID number for the POI in
question.
23
Exhibit VII – FIN Distributed User Role Grant Mapping
ROLENAME
All Funds
AM Asset Accountant
AM Asset Conversion
AM Asset Inquiry
AP Manager
Approve Budget Journals
Approve Encumbrance
Approve Journals
Approve PET
Approve PO
Approve Purchasing
Approve Requisition
Approve Transfer
Approve Vouchers
Apprv SPO Vchr
AR Receivables Entry
AR Receivables Inquiry
Auditor
Bank Reconciliation
BI Billing Entry
BI Billing Inquiry
BI Customer Admin
BI Customer Maintenance
Bursar
Campus Coordinators
Clinical Trials
cognos_approver
cognos_migrator
cognos_query_user
cognos_report_author
cognos_tester
Concur Maintenance
CU Customizations
ePro AP Manager
ePro AP Tech
ePro Approver
ePro Approver IA
ePro Approver International
ePro Approver Invoice
OUC Coordinator
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Campus Coordinator
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
24
ePro Approver Project
ePro Approver Subcontract
ePro Catalog
ePro Help Desk
ePro Inquiry
ePro Pilot
ePro Purch Agent
ePro Purch Dir
ePro Purch Manager
ePro Receiver
ePro Reporting
ePro Requestor
ePro Shopper
ePro Site Admin
ePro Supplier Enable
EXPControl
FIN Access
GL Allocations
GL Campus Manager
GL Campus Manager Display
GL Campus Trees
GL CampusTrees Display
GL Foundation
GL Foundation Display
GL Journal Generate
GL Journal Load
GL KK Admin
GL Project Maint
GL Suspense Correction
GL System Adjustment
GL System Admin
GL System Admin 2
GL System Manager
GL System Trees
Imaging
Incompatible Access User Maint
Inquiry
JE-Actual
JE-Budget
JE-BudgetInit
JE-Encumbrance
JE-PET
JE-Transfer
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
25
JE-Transfer Override
PC Project Entry
PC Project Inquiry
PeopleSoft User
PeopleSoft User CU
POs
Practice
Procurement Manager
PSC 1099
PurchAgent
Purchasing Manager
Query
Query Manager
Query Restrict
Receiver
Reports All
Reports Basic
Reports Batch
ReportSuperUser
Requisitions
SingleSignOn
SPINS
SPO Close
STARTUP
Treasury
Vendor Audit
Vendor Manager
View All
zANALYST
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
26