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
| Term | Definition |
|---|---|
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:
A typical CRM system provides the following functionality:
|
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.
| Step | Notes |
|---|---|
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. |
| Exception | Notes |
|---|---|
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. |
Emergencies | 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
