Build a clash-free timetable across every campus, in a fraction of the time.
Automated timetabling that resolves faculty, room and time conflicts before they reach a student. One scheduling engine for every department, programme and campus, not a spreadsheet per faculty.
The problem
Timetabling is where the whole institution collides.
Every term, the same fight: a professor double-booked, a lab clash no one caught, a room that seats 40 holding a cohort of 90, and a scheduler rebuilding it by hand across disconnected sheets. The timetable touches registration, attendance, faculty workload and exams, yet it is usually the least connected thing you run.
Three failures repeat every term: the schedule is manual and fragile, so one change ripples into ten clashes found only after publish. It is siloed per campus and department, with no shared view and no shared rules, so the same room is booked twice. And it is disconnected downstream, so registration, attendance and workload all re-enter the same data.
The operating model
One timetable, and the rules travel with it.
Four design choices turn scheduling from a term-end rebuild into an operating layer: one engine for every campus, constraints that prevent clashes instead of reporting them, preferences that carry weight, and a schedule the rest of the institution reads directly.
One engine, every campus
Departments, programmes and campuses schedule from a single instance with a shared room registry and shared rules, so a room cannot be booked twice and a cross-programme section is placed once.
Constraints prevent, they do not report
Faculty availability, room type and capacity, slot rules, commute buffers, holidays and validity windows are evaluated as the engine allocates, so a clash never reaches publish, let alone a student.
Preferences carry weight
Surveys and forms collect availability and priority, and a weighted index feeds allocation. The result is a timetable teaching staff accept rather than one they appeal.
The schedule is a governed object
Once approved, registration, attendance, faculty workload and exams read the same calendar. Nothing is exported, re-keyed or reconciled downstream.
What it does
Five things a scheduler needs. One engine.
Generation, faculty preference, room matching, the scheduler's own working style, and the governance that gets a timetable published. Pick one to see what sits inside it.
Generate a working timetable, not a starting point.
- Automated scheduling engine
- Department-level scheduling
- Cross-campus scheduling
- Cross-programme scheduling
- Conflict-free calendar engine, clashes prevented at source
- Scheduling data validator
- Schedule validity windows
Schedules people actually accept.
- Preference survey and form
- Weighted faculty preference index
- Availability and priority drive allocation
- Default teaching day and time preferences
- Commute-time buffer between sessions
The right space, matched automatically.
- Classroom type categorisation, lab, lecture, hybrid
- Course-based room requirements
- Classroom resource catalog, capacity and features
- Building information directory
- Campus master registry for multi-campus
Calendar, slot or template, their choice.
- Visual drag-and-drop calendar
- Filters by faculty, room and section
- Slot-based fixed time-block scheduling
- Reusable timetable template designer
- Recurring patterns such as MWF 10 to 11
- Academic session lifecycle and holiday calendar
- Google Calendar sync for stakeholders
Governed schedules, audit-ready reports.
- Multi-level approval workflow with roles and stages
- Status tracking through every stage
- Room utilisation and building usage reports
- Faculty load report
- Timetable clash report
- Primetime-hour report
- Unscheduled-section gap report
Inside the product
The whole scheduling cycle, in one place.
This is the application, not a diagram. Move through the surfaces your schedulers work in: generation, faculty preferences, rooms and resources, the calendar workspace, approval and publish, and utilisation reporting.
| Room | Type | Requirement matched | Fit |
|---|---|---|---|
| SCI-204 | Wet lab | Lab bench, fume hood, 24 seatsCourse requirement | Exact |
| MAIN-01 | Lecture hall | Cohort of 90, recording rigResource catalog | Exact |
| CITY-3B | Hybrid room | Blended delivery, 40 seatsCampus registry | Exact |
| ENG-112 | Studio | Design tables, 30 seatsBuilding directory | Alternate offered |
Lifecycle or product
The lifecycle is the operating model. This is the product that runs it.
Two pages, two jobs. Read the lifecycle to understand how scheduling connects to registration, attendance, workload and exams; read this page to see the application your schedulers open on Monday.
One of the institutional lifecycles: the governed model for timetabling, sections, faculty assignment and attendance.
The application that builds the timetable: generation, preferences, rooms, calendar workspace, approval and reports.
How does the calendar connect to registration, workload, assessment and estate planning?
What do schedulers, heads of department and faculty actually see and do in each screen?
The full operations model, including sections, attendance and academic calendar governance.
Generate to publish: constraints, preferences, rooms, approval, utilisation and clash reporting.
You are designing the operating model or comparing architectures.
See the lifecycle →
You are replacing a scheduling tool or a spreadsheet.
See inside the product →
Displacement
A scheduling tool solves scheduling. Then it stops.
CourseDog, Ad Astra and CourseLeaf are good at building a timetable. But the timetable is only useful when it moves: into registration, into attendance, into faculty workload, into exams. A point tool hands you a finished calendar and leaves the rest of the institution to re-enter it.
A file you export.
A governed object every lifecycle reads.
Re-entered elsewhere.
Fed automatically from the schedule.
Separate systems, manual sync.
One calendar, no re-entry.
Great at scheduling. Disconnected from curriculum, faculty and students.
Also part of the operating system
Class Scheduling is also part of Academic Operations.
Connect it and your timetable feeds registration, attendance, faculty workload and exams automatically: one calendar every lifecycle reads.
Built for every role
One timetable. Five views of the same term.
Generates a working term in one pass, then spends the time on exceptions, not rebuilds.
Publishes a schedule that registration and attendance read directly, with clashes and gaps cleared first.
Sees faculty load and room fit for the department before approving, not after complaints.
Submits availability once and gets a timetable that respects it, including travel time.
Utilisation and primetime reporting from the published schedule, not a survey.
What scheduling teams say about running the term on Creatrix.
Creatrix Campus has helped us centralise all student information in one reliable and intuitive system, improving efficiency and reducing errors. We use it to manage student data, schedule sessions, and automatically generate transcripts, which has simplified many of our academic processes.
Creatrix provides an excellent platform for timetabling within the School of Pharmacy, enabling teaching activities to be planned and coordinated through a clear line of sight to learning outcomes, assessments, professional competency standards, entrustable professional activities, and graduate attributes.
Go deeper
From the Creatrix library.
Blogs, whitepapers and case studies for the people who own the term: timetabling officers, registrars, deans and estate planning.
Frequently asked
Plain answers about scheduling.
Can it schedule across multiple campuses on one engine?
Yes. A campus master registry and cross-campus scheduling run from a single instance, so departments and campuses share one set of rooms, rules and calendars instead of a spreadsheet each.
Do faculty get a say?
Yes. Preference surveys and forms collect availability and priorities, and a weighted faculty preference index feeds the auto-scheduler before it allocates.
Default teaching-day and time preferences and a commute-time buffer between consecutive sessions are part of the same constraint set.
Will it catch clashes automatically?
The conflict-free calendar engine prevents faculty, room and slot clashes at generation, and the scheduling data validator checks the inputs first.
The clash report and the unscheduled-section gap report flag anything outstanding before publish.
Can we run it standalone?
Yes. It runs on its own, and it connects into the Academic Operating System when you are ready: your call on when to expand.
Does the timetable connect to attendance and registration?
On Creatrix, yes. The schedule is one governed object those lifecycles read directly, so sections, attendance sessions, faculty workload and exam windows all come from the same calendar. No re-entry.
How do schedulers actually build the timetable?
Whichever way suits the team: a visual drag-and-drop calendar with faculty, room and section filters, fixed slot-based time blocks, reusable templates, and recurring patterns such as Monday, Wednesday and Friday from 10 to 11.
The academic session lifecycle and holiday calendar are respected throughout, and Google Calendar sync keeps staff and students current.
Is the published schedule governed?
Yes. A multi-level approval workflow with roles, stages and status tracking sits before publish, and reports cover room utilisation, faculty load, clashes, primetime hours, unscheduled sections and building or room usage.
SEE IT ON YOUR OWN TIMETABLE
Bring a real scheduling problem. We will build it clash-free.
A tailored proof session uses your programmes, rooms and constraints, not a canned demo. Leave with a named, dated next step.