Jump to:
Overview
This document provides a comprehensive guide for universities looking to integrate their Student Record System (SRS) with Student CRM's Applications App. It outlines the steps involved in this process, including understanding the desired outcome, preparing the SRS for integration, and allocating tasks between the university, dev team, and Student CRM. The document also discusses key considerations such as preventing misunderstandings, scope creep, query changes, or loose contracted dev terms, as well as keeping project milestones on track.
The desired outcome is for the University (UNI) to regularly share applications data from the SRS via calls to Student CRM's API.
Technical documentation is available for the UNI's developer (DEV). Many other universities have successfully integrated with our API using this process, and we are available to provide assistance as needed.
It typically takes a couple of days' work for an experienced DEV; allowing one week should cover all contingencies. Reasons why integration may take longer than planned include misunderstandings, scope creep, query changes, and contracted dev terms that are too loose or milestones slipping.
The UNI must check that their DEV understands the desirable outcome, and any misunderstandings should be prevented by asking questions such as: “The desirable outcome is for our Establishment to regularly share applications data with the Applications app in Student CRM, sending it in via calls to the CRM’s API. Is that clear?”. Scope creep, query changes, or loose contracted dev terms can also be prevented through advance discussions, while project milestones can be kept on track with regular communication between all parties.
Coding is typically done by an experienced SRS staffer, SRS consultant, or freelance SRS dev working under the direction of the University.
Project plan
This plan outlines the key milestones for integrating a university's Student Record System (SRS) with Student CRM's Applications App. It begins with setting up a sandbox to test the API credentials and documentation, then proceeds through tasks such as selecting data update frequencies and criteria, writing scripts to connect to passive API endpoints, testing in sandboxes and live environments, analysing data, and progressing meetings. Finally, after any potential issues have been identified and resolved, the SRS-Student CRM integration can be signed off as complete.
This project plan provides a clear outline of the steps necessary for the successful integration of SRS with Student CRM's Applications App.
CRM | UNI DEV | UNI | Milestone |
✔️ |
|
| M01. Student CRM Sandbox created |
✔️ |
|
| M02. Student CRM Sandbox API credentials issued |
✔️ |
|
| M03. API documentation shared |
✔️ | ✔️ | ✔️ | 📆 M04. Kick-off meeting |
|
| ✔️ | M05. Data update frequency and selection criteria are chosen |
| ✔️ |
| M06. SRS Sandbox is created |
| ✔️ |
| M07. Script written to connect to Passive API endpoint |
| ✔️ | ✔️ | M08. Script tested using APV in Sandbox |
✔️ | ✔️ | ✔️ | M09. APV test data analysed using Use Case Matrix |
✔️ | ✔️ | ✔️ | M10. Progress meeting |
| ✔️ | ✔️ | M11. Further development and testing |
✔️ | ✔️ | ✔️ | 📆 M12. Progress meeting |
✔️ |
|
| M13. Live API credentials issued |
| ✔️ |
| M14. Scripts changed from Sandbox to Live |
| ✔️ | ✔️ | M15. Test run on a small subset of Live |
✔️ | ✔️ | ✔️ | M16. Test data analysed |
✔️ | ✔️ | ✔️ | 📆 M17. Progress meeting |
✔️ | ✔️ | ✔️ | M18. 7-day period to see if any issues arise |
✔️ | ✔️ | ✔️ | M19. SRS to Student CRM is signed off |
Responsibilities: Green = Student CRM. Blue = University.
Conclusion
Integrating SRS with Student CRM's Applications App can be a complex process, but it is possible to achieve with the right preparation and communication. This document has provided an overview of the integration process, from understanding the desired outcome to allocating tasks and preventing common pitfalls. With the help of this guide, universities can ensure that their SRS-Student CRM integration is successful.
We hope this information clarifies the process. If you have any further queries, don't hesitate to contact us. We are here to help.
Link to our documentation: Developers Centre
Glossary
Item | Definition More information can be found in our online glossary article |
API | Our Application Programming Interface, or API, is a set of software instructions and standards that allows machine-to-machine communication, with no ongoing human intervention required. Our API lets your Establishment share applications data from within your SRS to the Applications app in Student CRM. |
Applications app active (APS) | A module in Student CRM that is designed to help you manage the full workflow of direct applications. It handles the application forms, processes, communications, offers, etc, and provides an Applicant Portal for applicants to communicate, upload evidence, etc. |
Applications app passive (APV) | A module in Student CRM that is designed to help you manage the automated touchpoint sent out to applicants whose applications are being dealt within your SRS. |
Occurrence | A separate instance of an App, with its own settings and permissions. For example, "UCAS Applications" or "Direct Applications". |
Desired Outcome | For the University (UNI) to regularly share applications data from the SRS via calls to Student CRM's API. |
Integration Code | Code written by your UNI DEV, to run on your servers, to regularly send in all deltas to the API. |
Sandbox (CRM) | Student CRM configures a CRM Sandbox - a working copy of your Student CRM that's completely isolated from your live systems to allow you to test your workflows and touchpoints in a safe environment. |
Sandbox (SRS) | Your UNI DEV configures an SRS Sandbox - to allow you to test that your Integration Code is sending the correct data from a safe environment. |
Scope Creep | The UNI needs to know which applications from which applicants the DEV needs to find in your SRS each time the API is used. If the UNI makes changes to these queries (AKA ‘scope creep’) the DEV then needs to make further changes that will take more time. |
SRS | Your UNI’s Student Records System, ie: Agresso QL (Unit4), Banner (Ellucian), EBS (Tribal), SITS (Tribal), Unit-E (ESS - formerly Capita). |
Touchpoint | An automated contact with a student. Most commonly emails and SMS however letters and labels can be automatically produced for you to print and post. Touchpoints belong to one Workflow. |
Workflow | A series of automated App touchpoints that can be sent to any group of your applicants who all match a particular set of conditions. |
UNI DEV | An SRS-experienced UNI staffer, an SRS-experienced consultant, or an SRS-experienced freelance SITS dev, under the direction of the University. This individual is responsible for making the integration work. |
FAQs
Q. What is a Sandbox?
A. You can read more about what a sandbox is in this article.
Q. How often does the API sync our records?
A. This is up to you. You can set this from every 10 minutes to every day. Or, if you use cron, you would set up a cron task to call your script every 20 minutes, 1 hour, or 24 hours.
Q. What SRSs can Student CRM integrate with?
A. Our API is currently integrated with:
Q. What if I also want to send my enrolments data in?
A. Not a problem. There's more information about doing so in this article.
Q. Our Uni has not done this before, can we talk to somebody from Student CRM about it?
A. Yes of course. Just send in a ticket and we will get straight back to you to book a non-technical Zoom.