Getting started

Timetabler builds a weekly timetable for your school automatically. You describe what needs to happen — which teachers teach which subjects to which classes, how many times a week, in what kind of room — and the solver works out a schedule that fits everyone in without double-booking anyone.

Setting up a new school touches several pages, and they depend on each other in a specific order. Following this order the first time will save you from having to backtrack.

Setup order

1. Periods — build your week's time grid first. Every other page references periods (as unavailable times, locked slots, meeting slots, and so on), so this has to exist before anything else is useful.
2. Teachers, Rooms, Subjects, and Classes — the four basic resource lists. These don't depend on each other, so the order among these four doesn't matter.
3. Buildings (optional) — only needed if you want to group Rooms by building and configure a cross-building travel penalty. If you plan to use this, set up Buildings before (or alongside) Rooms, since assigning a Room to a Building happens on the Rooms page.
4. Departments (optional) — only needed if you want to block out shared meeting time for a group of teachers.
5. Lessons — this is the actual demand: "Mr. Smith teaches Math to 10A five times a week." Lessons reference everything above by name, so they have to come last.
6. Constraints — review the default soft-constraint settings (or adjust the weights) on the Constraints page before your first generate. You don't have to touch anything here to get a working timetable — the defaults are reasonable — but it's worth knowing what they do.
7. Generate — queue a solve. If it comes back INFEASIBLE, the result includes a list of what conflicts — see When generation fails for how to read it; fixing that list is usually a matter of loosening one hard constraint you set up in an earlier step (an unavailable slot that's too strict, a room tag nothing matches, and so on).

If you have a lot of data already in a spreadsheet, Bulk Import lets you skip typing it in one record at a time — it follows the same ordering as above (import teachers/rooms/subjects/classes before lessons, since lessons reference them by name).

Why this order

Every entity after Periods references something earlier in the list, by name or by ID — a Lesson doesn't make sense without a Subject, a Teacher, and a Class Group to point at; a locked or preferred time slot doesn't make sense without Periods existing yet. Setting things up in dependency order means you're never stuck picking from an empty dropdown.

See How the data fits together for a plainer-language tour of how these pieces relate, or jump straight to whichever record type you're setting up using the links above.