Special architectural considerations for Graduate Education Manager
Unlike student records systems, Graduate Education Manager is capable of managing highly individual student journeys during postgraduate research projects. As such, it is important that the integration architecture is set up in such a way that Graduate Education Manager’s full capabilities are available to the institution, while ensuring that the student records system continues to provide key reporting functionality.
Student information system is system of record
As it’s used to perform regulatory reports, typically the student information system will continue to be the system of record for some key information about the student. In this case, any workflows which request changes to this information will not actually make the change in Graduate Education Manager. A manual step, or an integration, will update the student records system. The next time the user sync runs, the field will be updated in Graduate Education Manager.
Graduate Education Manager is system of record
The following data is best managed directly in Graduate Education Manager, and we would recommend a data migration from the current source upon deployment:
- Project supervisors (as usernames)
- Project title
Where this data is used for additional processes outside of the scope of your Graduate Education Manager implementation, these fields may be managed in the student records system.
Dates
It is best to avoid syncing dates other than the start date, and use Graduate Education Manager’s date rules engine to calculate all project dates.
The project end date should be verified using a data import during the implementation process.