Teacher constraints

How to model teacher availability and unavailable periods

Separate periods a teacher cannot work from periods they would rather avoid. Mixing the two is a common cause of impossible timetables.

Juho Isola, Smootables founder

Constraint recipe

Availability has two levels. An unavailable period means the teacher must not be scheduled then, for example childcare, another campus, or a fixed part-time day. A preferred free period means they could teach then if needed and would rather keep it free. Mark true blockers as hard rules and requests as soft ones. Team-taught lessons need every teacher free in the same period.

Key takeaways

  • Unavailable means must not teach; preferred free means would rather not.
  • Part-time non-working days are unavailable periods, not preferences.
  • Write down the reason for each window; the reason decides the rule level.
  • Relax preferences before you weaken true unavailability.

Two levels, two different rules

A request to avoid Friday afternoon is not the same as a day the teacher does not work. Treating every request as mandatory quickly makes the timetable impossible, especially for shared specialists and part-time staff. The generator has no way to tell a childcare pickup from a mild preference unless your data does.

Write down the reason for each window: contract, campus travel, childcare, or preference. A contract reason blocks placement; a preference should only discourage it.

A worked example: one teacher's week, classified

Ms. Duarte teaches on two campuses. Wednesday is her day on the other site, Friday P5 and P6 are travel time back, and she would rather keep Monday P1 free for department planning. Three windows, but only two of them may block placement.

30 periods: 8 blocked, 1 requested, 21 open

MonTueWedThuFri
P1AvoidCampus B
P2Campus B
P3Campus B
P4Campus B
P5Campus BTravel
P6Campus BTravel
  • Unavailable (hard)
  • Preferred free (soft)
Empty cells are open for placement. If the Monday P1 request were coded as unavailable, her open periods would drop from 21 to 20 for no contractual reason.

The difference matters most for shared lessons. If Ms. Duarte team-teaches with a colleague whose only free afternoons are Wednesday, that lesson is impossible, and no generator setting will fix it. The overlap of the team's available periods is the real placement window, so check it before you promise the lesson can run.

Shared lessons need shared availability

Each teacher on a team-taught class must be free in the same period. Checking calendars one teacher at a time misses the real bottleneck: the overlap window for the whole team.

See teacher availability constraints for the full classification and examples.

Classify every window before generation

  1. List every availability note for each teacher with the reason behind it.
  2. Mark must-not-teach windows, including part-time non-working days, as unavailable periods.
  3. Mark would-rather-avoid windows as preferences unless policy requires otherwise.
  4. For shared lessons, draw the overlap of all required teachers' available periods and count whether the required lessons fit inside it.
  5. If placement fails, relax preferences first. Change a true unavailable period only when the underlying commitment changes.

Classification mistakes to avoid

  • Coding every teacher request as unavailable
  • Checking team members separately instead of their common free periods
  • Adding availability after pinning lessons, which can make the pinned slots illegal

In Smootables

Availability in Smootables is a hard rule: a period is either open or blocked, and the generator never places a lesson in a blocked one. Mark single periods on the teacher's availability grid, where each slot toggles between Available and Unavailable. For patterns, open Resources and use the availability rules: Dates when unavailable (full day) for specific days such as leave or trip days, and In-day time settings (repeating weekly) for recurring windows like another campus every Wednesday.

There is no separate soft level for periods a teacher would merely rather avoid, so keep genuine requests out of the availability data. A blocked period removes placements entirely; a wish belongs in your review of the generated timetable, not in the rules.

  1. Enter contract-level blockers as unavailability before you generate; pinned lessons that land inside a rule are flagged in Validation Errors.
  2. Leave preference requests unmarked, and check them by eye against the generated grid instead.

Quick answers

Is teacher unavailability always hard?

If the teacher truly cannot teach in that period, yes. A preference to avoid a period should usually stay soft.

Why can one part-time teacher affect many classes?

Every lesson needing that teacher must fit their working days and periods. Shared lessons also need the other teachers and the class free at the same time.

See how Smootables fits your school's constraints

Book a walkthrough. We will review your teacher load, rooms, and scheduling rules and show how they work in Smootables.