College of Business Timetable System (CoB-TMS)

Academic Scheduling · R Shiny · Conflict Detection · AAU College of Business

Case study: CoB-TMS — a complete timetable management platform with constraint-based conflict detection, room allocation, multi-role access, and publication workflows built in R Shiny.
Author

BRASS Digital Lab

Published

1 June 2025

Case Study # College of Business Timetable System (CoB-TMS)

Academic Scheduling · R Shiny · UAE Higher Education

✓ Live Deployment ✓ Conflict Detection ✓ Room Allocation ✓ Publication Workflow

Platform at a Glance

3 User Roles

Auto Conflict Detection

0 Double-Bookings at Launch

100% Timetable Publication Rate

1. Problem Statement

A UAE College of Business managed academic timetabling through a combination of Excel files, email coordination, and manual room booking — a process that regularly produced conflicts (double-booked rooms, faculty scheduling clashes), consumed two to three weeks of administrative effort each semester, and produced no structured publication format for students or faculty.

Key requirements: - Automated detection of scheduling conflicts (room, faculty, student group) - Structured room allocation with capacity constraints - Multi-role access for scheduling administrators and department heads - Publication-ready timetable output (PDF and web-accessible format) - Full revision history — every scheduling change logged

2. Solution Architecture

CoB-TMS is a modular R Shiny application covering the complete timetabling lifecycle: data setup, constraint definition, draft building, conflict resolution, and published output.

2.1 Technology Stack

Component Technology Purpose
Application R Shiny + bslib Reactive scheduling interface
Database SQLite via DBI / pool Courses, rooms, faculty, constraints
Tables DT Filterable timetable views
Conflict Engine Custom R logic Constraint-based conflict detection
Publication R Markdown + LaTeX PDF timetable generation
Access Control RBAC (3 tiers) Role-appropriate editing rights
Hosting shinyapps.io Production deployment

2.2 Constraint Model

The conflict detection engine evaluates four constraint classes simultaneously on every scheduling action:

📍 Room Constraints

  • Room capacity vs. enrolled student count
  • Room type (lecture hall / seminar room / lab) vs. session type
  • Room availability (existing bookings, blocked maintenance periods)
  • Building/campus preferences where applicable

👤 Faculty Constraints

  • Faculty existing commitments (no parallel sessions)
  • Maximum weekly teaching load enforcement
  • Faculty availability windows (preferred/unavailable periods)
  • Cross-department shared faculty management

👥 Student Group Constraints

  • Cohort clash detection (same programme, same year group)
  • Core vs. elective session prioritisation
  • Back-to-back session rules (minimum break periods)
  • Split group management for large cohorts

📅 Time Constraints

  • Institutional working hours enforcement
  • Prayer time slot management (UAE-specific)
  • Public holiday and exam period blocking
  • Minimum/maximum sessions per day per room

2.3 Publication Workflow

Draft mode → Department review → Head approval → Published
     ↕                ↕                ↕
 Edit freely     Flag issues     Lock for term

Each stage has distinct role permissions. Published timetables are locked against editing; a revision cycle re-opens draft mode under a new version number, preserving the published record.

3. Outcomes

✅ Scheduling Outcomes

  • Zero room double-bookings in first semester of live operation (down from 12–15 conflicts in the previous manual cycle)
  • Timetable build time reduced from 3 weeks to 4 days
  • First conflict-free published timetable in 3 semesters
  • Prayer time slots and UAE public holidays automatically excluded

📋 Administrative Outcomes

  • Full revision history of every scheduling change with author and timestamp
  • Department heads access read-only draft view without editing ability
  • PDF publication with institutional branding generated automatically on approval
  • Faculty load reports generated in one click vs. manual Excel compilation

4. Lessons Learned

Constraint definition is 80% of the project. The conflict detection engine is straightforward R logic — but capturing every institution-specific constraint accurately requires extensive workshop time with administrators, department heads, and the academic registrar. This scoping phase was extended from 1 week to 3 weeks on this project, and it was the right call.

Prayer time management is a UAE-specific requirement that generic timetabling software consistently handles poorly. CoB-TMS builds prayer time windows into the core constraint model, not as an afterthought. Jumaa prayer on Fridays is enforced as a mandatory scheduling gap.

Version numbering for timetables is essential. Faculty and students need to know which timetable version they are looking at. CoB-TMS implements semantic versioning (T1-2025.v1, T1-2025.v2) with a published changelog per version.

Need an Academic Scheduling Platform?

🤝 Request a Consultation 🔧 View All Services

Back to top