Building the timetable
Several planners working on the same timetable at the same time
Timetabling is a few intense weeks a year, and in those weeks one person is a bottleneck. Multi-user mode lets two, three or more planners build the same timetable at once — without the last one to press save quietly overwriting everything the others did.
- Switched on once, for everybody
- Changes appear within ten seconds
- Ownership is per course
- Free 12-page manual, published below
What goes wrong without it
Not a clash. Silence.
A timetabling application built for one planner behaves exactly as you would expect: you load the timetable, you change it, you save it, and everyone else sees the result afterwards. That is correct and sufficient for eleven months of the year.
In the two weeks when three people are building next year, it fails in the worst possible way. Whoever saves last overwrites whatever the others did in the meantime, and nobody is warned. The work is not flagged, not merged and not recoverable — it is simply gone, and it is usually discovered days later by a lecturer whose Tuesday moved back.
Multi-user mode exists for exactly that fortnight. It is part of the licence, not an edition or an add-on.
Switching it on: one person, one minute, once
It is a property of the timetable, not of the computer — so nobody has to visit anybody’s desk.
Give every planner their own name
Settings → Miscellaneous → General, the “User” field. It has to be different for each person and recognisable to a human, because it is the name your colleagues will see when a course is held. Institutions using the desktop login screen have this filled in already.
Load the timetable from the database
Data → Load From Database, so you are starting from what the database actually holds rather than from a local copy.
Tick one checkbox
Settings → Miscellaneous → View tab: “Sync courses for multiple users”. Confirm with OK.
Save the project back
Data → Save To Database. This is the step people forget and the one that matters: the setting is stored inside the project, and the project lives in the database.
Everybody else does nothing
The next time a colleague loads from the database, the setting arrives with the project and their copy switches itself into multi-user mode. No second machine to configure, no instruction to circulate.
What is exchanged, and how often
Every ten seconds, and only while somebody else is actually working.
Each copy of the application talks to the database on a ten-second tick. It reports that it is still there, sends up the sessions you have moved since the last tick, and brings down the ones your colleagues have moved, redrawing your grid if any of them are on the screen you are looking at.
If you are the only planner logged in, none of this runs. Your work reaches the database when you save it, exactly as it did before, so multi-user mode costs a lone planner nothing at all.
What travels this way is the timetable itself — the day, hour, room and week of each session. Structural changes do not: a new course, a changed number of hours, a new student group, room or lecturer reaches your colleagues when somebody saves to the database and they load from it. That is deliberate, and it is the one thing worth telling a new team on day one.
- A copy that stops reporting — closed, crashed, switched off — is treated as gone after about five minutes
- Sessions move on the other screens within roughly ten seconds
- Structural data travels on save and load, not on the tick
- Automatic minute-by-minute local backups pause: the database, not your local file, is now the truth
Ownership is taken per course, and taken silently
The library model: while you have it, nobody else can.
The moment you begin to do something to a course — open its screen, drag one of its sessions, split it, lock it, write its web note — that course becomes yours. You are not asked and no dialog appears. If it was free, it is simply yours.
The unit is the course, not the single session. Take Mathematics I and you have taken every lecture, tutorial and lab in it, because moving one session of a course almost always means moving the others.
A colleague who reaches for a course you are holding is asked — by name — whether to claim it from you. Answering no cancels their click cleanly and costs them nothing, which is why it is the right answer almost every time: the name in the message tells them exactly who to walk over to. Their copy meanwhile leaves your course alone entirely: it is not overwritten by their save and not pulled down onto their screen while you are still working on it.
Claims are handed back automatically when you cancel, when you close a course screen having changed nothing, when an action is abandoned, and when you close the application normally — that last one releases everything at once. A course with unsaved changes stays yours until you close, which is the point rather than a defect.
Operations that behave differently while colleagues are working
An operation that touches a hundred courses cannot ask a hundred questions, so each one has a defined answer instead.
| Operation | What it does | Why |
|---|---|---|
| Automatic generation, and the six optimiser actions | Refuses before changing anything, and lists the held courses with the name of the person holding each | Generation rewrites most of the week. Running it around somebody else’s work would leave a timetable that is partly generated and partly not. |
| Shifting the weeks of a term | Refuses in the same way | It moves the boundary every course is measured against, so it has to move all of them or none. |
| Enable all schedules; adjust corner weeks to lectures | Runs on everything that is free, then names the courses it left alone | The message replaces the usual “operation successful”, so a partial run is never mistaken for a complete one. |
| Adding or changing student groups | Not permitted while anyone else is logged in | Groups are the skeleton the whole timetable hangs on. Changing that underneath a colleague is not something any program can make safe. |
When a course is stuck
A claim survives a crash on purpose — so there are two buttons that clear one.
If a machine is switched off, killed in Task Manager or loses the network at the wrong moment, nobody was there to hand the claim back and it stays in the database. That is the correct trade: the alternative is a claim that evaporates while somebody is still editing behind it.
Clean Owners, at the foot of the same View tab, releases every course held by everybody, clears the list of logged-in users and empties the queue of undelivered changes, then records in the history log that you did it. It is blunt by design and is best treated as an administrator’s action, agreed with the others first — it releases claims that are protecting real unsaved work as well as the abandoned ones.
Clean Sync is the gentler cousin: it clears the logged-in list and the undelivered queue but does not touch ownership. Use it when the application insists other users are logged in and you know there is nobody there. If you are not sure which you need, this is the one to try first.
One house rule prevents most of it: close the application when you leave for the day instead of letting it run overnight. Every claim, release, clean-up and refusal is written to the application’s own log with names and times, and the log opens from a button inside Settings, so a support question is usually answered from the file rather than from memory.
Questions institutions ask
How many people can plan at once?
There is no fixed limit in the mechanism. In practice this is a feature for the two, three or four people who build a faculty’s timetable together, and that is the size it is designed and tested around.
Do we have to run it all year?
No, and most institutions do not. Switching back is the same panel: untick the box, press Clean Owners so no course is left marked as belonging to anybody, and save to the database. Nothing is lost either way, so running multi-user mode for the two busy weeks and single-user mode for the other fifty is a perfectly reasonable way to work.
What happens to work in progress if somebody’s machine dies?
Whatever they had already saved is in the database. Whatever they had not is lost with the machine, exactly as it would be in single-user working — but their claim stays, so nobody else silently overwrites the course while they restart. An administrator clears it with Clean Owners once they are back.
Is this the same thing as the “sync reservations” setting?
No, and the two are easy to confuse because both say “sync”. Sync reservations with database, on the General tab, keeps room bookings in step and has nothing to do with several planners. The one this page describes is Sync courses for multiple users, on the View tab. The manual opens with that warning for the same reason.
Can several faculties work on separate timetables at the same time?
That is a different question with a different answer: separate timetables are independent and never needed this. Multi-user mode is for several people inside one timetable. Connecting the timetables of separate faculties covers the other case.
Is there a document we can give the team?
Yes — the manual below, in English or Slovenian. It is twelve pages, written for planners rather than administrators, and it quotes the exact wording of every message they will see.
Download the manual
- Working on the same timetable at the same time (PDF, 12 pages)The whole of multi-user mode for the people who will use it: switching it on, what happens on the ten-second tick, what claiming a course means, the exact wording of every message, what to do when something is stuck, and how to go back to single-user working. Free, and no form to fill in.
- Sočasno delo na istem urniku (PDF, slovensko)The same manual in Slovenian, for institutions whose planners prefer it.
- All published manualsEverything else we publish openly, including the 112-page import reference.
Related capabilities
- Automatic generationThe operation that refuses to run while a colleague is still holding a course, and why that is the right behaviour.
- Conflict detectionWhat catches a clash once several people are moving sessions at once.
- Connecting facultiesThe other kind of shared work: separate timetables in one university.
- Documentation and manualsIncluding this manual and the import reference, published free.
See Wise Timetable on your own data
Book a 45-minute online presentation. We will walk through your institution's scheduling problem, show how Wise Timetable handles it, and answer anything your team wants to test.