Integration
Integrating your timetable with your SIS
Integration with an unfamiliar external system is the single most common reason a timetabling implementation runs late. It is also the most avoidable, if it is scoped honestly at the start.
Decide which system owns what
Almost every integration problem is really an ownership problem.
Before any technical work, agree which system is authoritative for each kind of data. Typically the student information system owns programmes, modules and enrolments; HR owns staff records; estates owns the room inventory; and the timetabling system owns the schedule itself and the constraints behind it.
Where two systems both believe they own something, they will diverge, and the reconciliation work will land on whoever complains least. Writing the ownership map down before integration starts is twenty minutes that saves months.
Which direction data flows
- Inbound to the timetable: programme and module structure, enrolments and group sizes, staff records and departments, room inventory and capacities.
- Outbound from the timetable: the schedule itself, to your portal, virtual learning environment, mobile app, digital signage and calendar feeds.
- Bidirectional, occasionally: room bookings, where a facilities system and the timetable both create reservations. This is the hardest case and worth avoiding if you can.
Files, APIs, or scheduled synchronisation
File-based exchange — Excel, CSV or XML export and import — is the most widely supported route and perfectly adequate where data changes a few times a term. It fails where currency matters, because the timetable is only as fresh as the last export somebody remembered to run.
A documented REST API allows scheduled synchronisation, so changes propagate without human involvement, and allows your own systems to read timetable data in real time rather than displaying yesterday's copy.
Direct database integration is fastest and most fragile, and should only be considered where both systems are under your control and institutional policy permits it.
Scoping it honestly
Ask any prospective vendor two questions: have you connected to this specific system before, and what does the work look like if you have not? A vendor who answers the second question vaguely is telling you something.
Then find out, internally, whether your SIS actually exposes a usable API or only a reporting export. The answer is frequently not what the vendor of that system claims, and it is much better discovered in evaluation than in month three.
Single sign-on is worth settling at the same time. Shibboleth and comparable federated identity systems are widely adopted in higher education, and using yours removes an entire class of credential administration.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.