Policy - Colleague ERP General Practices

1.0 Policy Statement

This policy establishes the Colleague ERP General Practices Policy for users of the Colleague ERP system.  The continued successful operation of the Colleague ERP system requires knowledge of information security, a high degree of communication, cross training, proper implementation of system changes, engaging consulting support, duplicate record checking, and accurate record creation.  Users of the Colleague ERP system are responsible for following the requirements set forth in this policy and reporting violations to the ERP Steering Committee.

2.0 Reason for Policy/Purpose

The Colleague ERP system is critical to CalArts’ academic and operational mission.  The purpose of this policy is to establish general practices to ensure successful operation.

3.0 Applies To       

This policy applies to all UI users of the Colleague ERP System.

4.0 Policy/Procedures

4.1 Colleague Information Security

Users of the Colleague ERP system are given access to a wealth of information in order to conduct the daily operations of the Institute. Personnel, student, financial, health and Library information maintained by CalArts is considered confidential.  Access to this confidential information and any other information made confidential by law and/or CalArts’ policy is limited to those individuals whose position requires use of this information.

Users that need access to the User Interface (UI) of the ERP system must complete the following:

  • Sign CalArts’ Data Access and Security Form which will remain on file in the Human Resources Department.
  • An Information Technology Ticket must be created by their department supervisor that identifies what security role or specific forms the user will have access to in the system.
  • Attend General Colleague training conducted by the ERP Project Manager.  The training must be completed in the “Test” Environment before working in the “Production” Environment is authorized.
  • Attend FERPA training conducted by the Registrar’s office.

4.2 Communication

Colleague is the primary business system for the Institute and is integrated in to the day-to-day operations of each department.  Constant communication is the key to success in any environment, but it especially vital for the successful operation of an ERP system.  Every action that is taken in Colleague can directly impact the operations of any other department and their data.

Colleague requires constant interdepartmental coordination.  The ERP Project Manager’s primary responsibility is maintaining this coordination, and it is therefore required that each department work closely with the ERP Project Manager. 

Mass Email Notifications to students is another important communication tool.  However, emails that are sent may have an effect on another department’s communication or students may contact other departments about the communication and not just the department that sent it.  To address these potential issues it is important to keep all departments notified by sending a copy of the Mass Email to all departments as well as the ERP Project Manager.

4.3 Cross Training within a Department

Each department has specific and specialized ERP operational tasks.  If a single individual has sole knowledge of these departmental tasks this puts the Institute at risk, especially if that individual moves offices or endeavors outside of the institute. To mitigate this risk each department is required to have a “backup” person versed in the department’s ERP operational tasks. 

One way to achieve consistent cross training is to switch day-to-day tasks between the primary and backup individual on a monthly basis.  Cross Training on tasks that occur less frequently (e.g. once a month, quarterly, etc.) are best handled by both the primary and backup user until either can complete the process independently.

Once both the primary and backup users can independently complete these tasks they must document the necessary steps.  Documentation must be stored on a network drive that is accessible to the department as a whole.

4.4 Implementing System Changes

Changes to Colleague system must only be done after extensive planning, coordination, testing, and involvement with the ERP Project Manager.  Making a system change not only effects your department, but can adversely affect reporting, system processes, and other departments’ operations.

Examples of what constitutes a System Change:

  • Creating/Modifying/Deleting a Val Code or Table
  • Creating/Modifying/Deleting a Rule
  • Change in Business Practice/Processes

If a system change is indeed necessary the following steps are required:

  1. Request approval from the ERP Project Manager for any change to be made to the system that could affect reporting or the operations of another department
  2. Inform the other departments (with a copy to the ERP Project Manager) of the anticipated change and request input regarding any potential adverse effects to their operations. 
  3. Resolve any issues that arise before proceeding with the next step
  4. Make the change in the most recently cloned test environment and coordinate with the ERP Project Manager and the other affected departments to thoroughly test multiple scenarios.
  5. Document the change and the testing procedures performed
  6. Request final approval from the ERP Project Manager
  7. Make the change in Production and inform the other departments (with a copy to the ERP Project Manager) that the change has been made

4.5 Consultant Support

Departments may not engage consultant support directly.  Consultant support is costly and most issues can be resolved without the need of a consultant.  All requests for consultant support must be sent to the ERP Project Manager.

The ERP Project Manager must be included in all communications, meeting invites, and conference calls with any consultants as these engagements may involve changes to the system or may impact other departments’ operations.

4.6 Department of Authority - Core Data

Department of Authority defines which office is authorized and responsible for creating, modifying, and maintaining Core Data for a specific constituent type.  Each Department of Authority is solely responsible for the accuracy and integrity of the data they “own”. If a change of Core Data is necessary, then a request must be sent to the proper Department of Authority in order for the change to be made.

Department of Authority

Core Data


Vendors - if NOT already in system as a Faculty/Staff/Student


Creation of Student/Parent Records through Hobsons’s Import. Institutions (e.g., new schools) entered by Admissions and coordinated with Registrar’s Office, if needed.


Donors and Foundations in Salesforce Only

Human Resources:

Faculty/Staff/Student Employment Data Only

Information Technology:*

Student/Alumni/Faculty/Staff - CalArts Email Address Only


Student/Alumni/Student Workers

Student Affairs:*

Request Only – Change Preferred Name Field


4.7 Accuracy of Data Entry

Accuracy and the timeliness of data entry in the ERP system is essential to the successful operation of the ERP system.  The Institute relies on accurate information to make informed decisions, for the system to run processes correctly, and be able to produce correct and timely reports. 

To ensure the accuracy of information it is required for each department that enters or modifies data in Colleague to run regular audit reports to look for and correct irregularities in the data.  Any and all irregularities must be reported to the ERP Project Manager.

4.8 Duplicate Checking and Record Creation

To minimize inaccurate or incorrect data, Departments who are authorized to create an original record must check for any existing records before adding a new record.  Remember, once entered, a record cannot be deleted from the database.

Before adding a new record in Colleague, duplicate checking is required using three of four different types of look-ups to determine if the record already exists.

  • Enter the Colleague ID Number
  • Enter the Social Security Number or Employer Identification Number
  • Use a partial name lookup three different ways:
    • First 3 letters of last name - comma - first 3 letters of first name (e.g. doe, jan)
    • Full last name - comma - first letter of first name (e.g. doe, j)
    • Full last name by itself (e.g. doe)
    • Advanced Person Search

If no record exists, and you are the Department of Authority, a new record can be created following Minimum Data Entry Standards.

4.9 Minimum Data Entry Standards

The Minimum Data Entry Standards establishes a set of required information before a record can be created in Colleague.  Adhering to the Minimum Data Entry Standards will make searching for a record easier, increase reporting accuracy, and help in avoiding the creation of duplicate records. 

The following information is required to create a new record in Colleague:

  • First Name (Legal name, no shortened names or nicknames)
  • Middle Name (Only populate if provided the information)
  • Last Name (Legal name used for tax reporting purposes)
  • Address (NAE > ADSU > ADDR – This will be the Preferred Address as Colleague sees it unless otherwise changed on the Person Addresses, ADR form)
  • Birthdate
  • SSN, if given

4.10 Duplicate Records

Duplicate records can cause havoc in every area of Colleague.  Duplicate records cause inaccuracies and confusion for employees and students alike throughout Colleague.  Correct information can be tied to the wrong record and be misrepresented in reports and other data.

Unfortunately, once a duplicate record is created it is permanently in the system.  To minimize the impact of a duplicate record in the system, an IT ticket must be created immediately to start the duplicate resolution process. 

4.11 Further Information

Further information on data entry can be found in “Colleague Data Entry Standards Manual - California Institute of the Arts February 2014”.

5.0 Policy Compliance

Violations of this policy may result in removal of access privileges and also in disciplinary action.

6.0 Contacts

ERP Steering Committee


7.0 Revision History

Responsible Official:

Michael Carter

Responsible Office:

ERP Steering Committee

Origination Date:

October 20th, 2015

Approved By:

ERP Steering Committee

Approval Date:

October 20th, 2015

Effective Date:

October 20th, 2015

Next Scheduled Review:

October 20th, 2016

Have more questions? Submit a request


Please sign in to leave a comment.