Chico State 360

Policies and Procedures

The Chico State 360 CRM solution is an enterprise-wide application.  Application management policies and procedures have been put in place to ensure that the system continues to provide value to campus and to ensure continued stable operations.

Change Management

Scope & System Goals

Change management processes must be followed when changes are made to campus Constituency Relationship Management (CRM) services. This includes all the environments and services of Salesforce, TargetX, Fonteva, FormAssembly, Informatica, and DemandTools.

Our goal of increasing campus adoption of the CRM requires a commitment to:

  • Keeping our systems stable and online
  • Ensuring system software is current
  • Testing all changes before going into production
  • Properly communicating with campus by filling all RFCs at least one week ahead of time

Constituency Relationship Management (CRM)

Is a set of processes and supporting technologies used to acquire, retain and enhance the relationships with all different constituent groups  who interact with CSU, Chico. These groups include:

  • Future students
  • Continuing students
  • Alumni
  • Parents
  • Donors
  • Staff
  • Faculty
  • Community partners

A typical CRM system provides the following functionality:

  • Manage members: including member sign-ups, database management, and analysis
  • Campaign management: personalized email blasts, newsletters and call campaigns
  • Manage events: including online registration and participant tracking
  • Manage social media: social media communications with constituents

Instance Management

CSU Chico currently manages several instances of Salesforce/TargetX: one is the production system (org), while the others are used for system testing, functional testing, and development.

Request for Change (RFC)

Before changes are made to production CRM components, the CRM team will create an RFCat least a week ahead of time to allow for testing and discussion.

Change Advisory Board (CAB)

CAB meets weekly to review all system changes and discuss their potential impact on campus operations. Each proposed change is voted on for approval. Issues and changes to the process are discussed by the board.

Major Releases and Updates

Major releases, such as service packs or similar upgrades, to any CRM component may require a substantial effort. Therefore, a project plan should be completed before any updates are applied in product and before non-production implementation and testing.

Chico State 360 Advisory Group

The Chico State 360 Advisory Group includes representatives from Student Affairs and Academic Affairs, who participate in meetings twice a month to discuss topics related to CRM governance, support and future projects.

System Schedule

Salesforce schedules three major releases a year in the spring, summer and winter. These releases are automatically applied at the designated date and time by Salesforce. Institutions are given advanced notice with time to test in development prior to the update.

TargetX typically releases monthly updates to some or all of their available applications. CSU, Chico will schedule bi-annual TargetX updates in the winter and summer. Additional updates may be necessary if TargetX releases critical updates to their applications.

Database and Application Patching

The CRM team will monitor, and consult with stakeholders, about any updates that are available for Salesforce/TargetX and its associated services. These include custom objects, FormAssembly, cumulative updates and new TargetX releases, Salesforce releases, and Database patches.

Before going into the production system, each of these must be first evaluated against their urgency and impact to the system. Based on that evaluation, the CRM team will suggest the priority order of the maintenance schedule for review by the Chico State 360 Advisory Group.

Once approved by the Chico State 360 Advisory Group, the CRM team will update the published calendar highlighting the milestones listed in the process below. In addition, the CRM team will then prepare a set of system and functional testing plans that are appropriate to the changes proposed.

Normal Process

Non-production install

ADS will install changes, including patches and other updates in non-production systems

System Testing

ADS and the Constituency Relationship Manager will be primarily responsible for testing.

The length of time spent in testing will depend on the number and impact of the proposed changes, with a minimum of one week in testing before moving into production.

Functional Testing

Departments impacted by the changes will be responsible for functional testing.

The length of time spent in testing will depend on the number and impact of proposed changes, with a minimum of one week in testing before moving into production.

Final Go/No Go decision

The functional stakeholders and ADS will report on test completion and make a final decision regarding a move to production.

RFC Created

If a go-ahead decision is reached, ADS will create an RFC.

RFC Approved

If CAB approves the RFC, ADS will schedule any necessary downtime for production maintenance.

Changes Installed

ADS will install the change, including application shutdown as needed.

Changes will typically be made in the CRM standard maintenance window, Thursdays from 5:00 am to 8:00 am.

Exceptions to the Normal Process

Blackout Periods

At the start of the fall and spring terms, we will not schedule changes during a 2-week blackout period. These periods will begin one week before the term begins, and one week before finals week.

These blackout periods will typically occur in January, May, August, and December.


Emergency patches to resolve security issues, system instability, and similar issues may bypass some or all of this process.

Zero-day Vulnerabilities

Patches to fix zero-day security vulnerabilities will be evaluated on a case-by-case basis.

Development Lifecycle

Development Lifecycle