Skip to content

Generating and publishing

With the setup complete, create a timetable and run the generator.

It works through the allocations and constraints and produces a schedule that satisfies them. On a school of any size this takes a little time — let it finish rather than stopping and restarting it.

The generator reports what it could not place. Read that list; it is the most useful output of the run. Unplaced lessons are nearly always one of:

  • Lesson counts exceeding available slots — do the arithmetic per class.
  • A teacher over-allocated — more lessons assigned than periods they are available for.
  • Too few specialist rooms — three classes needing the one laboratory at once.
  • Conflicting constraints — two rules that cannot both hold.

Fix the cause and generate again. Placing the leftovers by hand without fixing the cause produces a timetable that breaks the moment anything changes.

Keep the failed result panel open and read What to correct. For recognised setup problems, ShuleOne names each affected class, compares required weekly teaching time with available time, and shows the exact shortage. Select Open class lessons to go directly to that class’s lesson requirements.

For example, if a class needs 22 hr 45 min of lessons but only 21 hr 40 min remains after breaks and unavailability rules, the panel reports a 1 hr 5 min shortage. Correct it by reducing that class’s weekly lesson time, or by restoring at least the same amount in Slots, Bells, or Constraints.

ShuleOne also checks whether a teacher’s single, double or triple sessions actually fit inside the allowed clock windows. A total of six free periods is not enough for three double lessons if breaks split those periods into blocks of three. In that case, Timetable → Issues names the teacher and subject, shows the number of sessions required and the maximum that can fit, and stops generation before the engine reaches its time limit. Open another consecutive window, shorten the session pattern or reassign a lesson.

When a failure is not a recognised setup problem, Technical details distinguishes a time limit, an engine process error, unreadable or missing engine output, and a result rejected by hard-constraint validation.

Use the detail together with Timetable → Issues:

  • A timeout means the engine ran out of its configured generation time. Review the most restrictive constraints and over-allocated teachers, including whether double and triple sessions have enough consecutive periods, then try again.
  • Missing or unreadable engine output is a server-side engine problem. Copy the full diagnostic when reporting it to support; changing lessons at random will not fix it.
  • A hard-validation failure means ShuleOne found clashes in the generated result and did not save the unsafe schedule. The failure panel lists what conflicted.

Do not dismiss Technical details before copying an unrecognised server-side diagnostic if you need support.

Open a class’s lesson requirements when a subject should be distributed across the week. The lesson’s spread settings have two distinct behaviours:

  • Prefer spreading these sessions across different days is a preference at the normal priorities. The generator may put two sessions on one day when teacher, room, availability or capacity restrictions leave no better complete timetable.
  • Set Priority to 10, keep spreading on, and leave Same-day minimum gap at 0 to require different days. This is a hard rule: the generator leaves the lesson unplaced or fails validation instead of silently adding a second session that day.
  • Set a positive Same-day minimum gap when same-day repeats are acceptable but must be separated. This permits controlled repeats and keeps the configured number of teaching periods between their start times; breaks do not count as teaching periods.

Use the Subject once per day constraint when the rule applies to a subject and class regardless of the lesson’s spread priority. A hard Subject once per day constraint is enforced even when the class uses every available teaching period. If the weekly demand cannot fit under that rule, correct the lesson counts, availability or other constraints instead of expecting the generator to relax it.

Use Settings → Scheduling rules → Enforce one subject per class per day when this is a school-wide policy. This is a hard rule and deliberately overrides every lesson’s optional spread preference. Before generation, Check setup compares each lesson’s separate sessions with the distinct days left by class, subject and teacher availability. If, for example, two CAD singles are allowed only on Friday, ShuleOne names that lesson, reports “2 sessions but only 1 available day”, and blocks generation. Open another day, reduce the separate sessions, or use a double where a legal consecutive window exists.

Locked placements now remain exactly where they were pinned when Generate is run. ShuleOne keeps the original locked allocation, including its day, period, room and co-taught class rows, even when the generation engine returns only a partial result. Only unlocked placements are replaced.

Priority-10 different-day lesson settings and hard Subject once per day constraints are now checked consistently by both timetable engines and by final hard-constraint validation. Fully occupied class timetables no longer cause these hard rules to be silently relaxed. Normal-priority spreading remains a best-effort preference.

The school-wide Enforce one subject per class per day rule is now included in setup checks and timetable diagnosis before the scheduling engine starts. When availability leaves fewer distinct days than a lesson has separate sessions, the issue names the lesson, required sessions and available days instead of allowing generation to end with an unexplained timeout. Lesson editors now identify their spread option as a preference and explain that the school-wide rule takes precedence.

The lesson working area now stores unallocated placements on the server. Moving a lesson there immediately frees its former slot, and the lesson remains in the working area after a page refresh until it is placed again or a fresh generation is started. Schools using the timetable’s standard slots, without a separate bell profile, can place these lessons back into any highlighted teaching slot without a false “no teaching slot” warning. Each working-area lesson is now shown as a full-size card with a readable subject and class label instead of retaining the grid’s compact tile size.

Timetable versions and publication status

The timetable list identifies draft and published versions before you open a grid.

Look at it three ways, because each shows a different kind of problem.

A timetable by class

By class — the view students and class teachers use. Check for gaps in the middle of the day, the same subject twice in a row where it should not be, and heavy subjects stacked in the last periods.

A timetable by teacher

By teacher — check the load is reasonable and fairly spread. Look for six consecutive periods, a teacher with no break, and days that are far heavier than others.

A timetable by room

By room — check no room is double-booked and that specialist rooms are used sensibly.

The grid allows manual moves for the cases judgement handles better than a rule.

ShuleOne checks each move and refuses one that creates a clash — a teacher in two places at once, or a double-booked room. If a move is refused, something else has to move first. The message This class has no teaching slot at the selected period now appears only when the class genuinely uses a bell profile that does not contain that period; it is not shown for classes using the timetable’s standard slots.

To free a slot before deciding where its lesson should go, drag the lesson into the Lesson working area below the grid. This genuinely unallocates the placement; another lesson can use the former slot immediately. The unallocated tile is saved, so refreshing the page does not return it silently to its previous position. Drag the tile from the working area into any highlighted safe slot to place it again. Co-taught or merged class rows move into and out of the working area together for that particular session. Working-area cards display the subject and class clearly; a grouped lesson displays the number of classes that will move together.

Manual moves also refresh the lesson’s period and clock-time details together. Class timetable reports therefore print each lesson in its selected grid slot instead of combining lessons that were moved from different times.

Starting Generate includes working-area lessons in the new solution and clears the working area. Generation still replaces all non-pinned manual placements.

Lock a placement when it must stay on its current day and period while the rest of the timetable is regenerated. A locked co-taught lesson keeps all of its participating class rows together. Lock all freezes the complete current timetable; generating after that does not move or remove any of those allocations.

Unlock the placements you want the generator to reconsider. If a locked placement now conflicts with a changed lesson requirement, bell schedule or hard constraint, ShuleOne keeps the locked allocation and reports the conflict instead of silently replacing it.

Keep manual changes few. Each one is a decision the generator does not know about, so regenerating discards them. If you find yourself making twenty, express the underlying rule as a constraint and regenerate instead.

Publishing makes the timetable the live one. It then appears:

  • To teachers, on their own dashboard.
  • To students and parents in the portal.
  • On the printed grids for classrooms and the staff room.

Print the class grids, the teacher grids and a master copy for the notice board.

Mid-term changes happen — a teacher leaves, a class splits. Make the change on the published timetable rather than generating a new one, and then tell people. A timetable that changed quietly is worse than one that is slightly wrong, because half the school is working from the version they printed.

Timetable → Reports covers teacher load, room utilisation, subject distribution across the week, and any remaining gaps.

Teacher load is the one to check before publishing. A timetable that is valid but gives one teacher 32 periods and another 14 will not survive contact with the staff room.