Key takeaways
- Unavailable periods are hard constraints; preferred free periods are soft.
- Part-time days off are availability rules, and the most frequent clash source.
- Availability narrows a whole teaching team, since shared classes need common free time.
- Two part-timers on one team can shrink common availability enough to break feasibility alone.
Two forms, two strengths
Unavailable periods are commitments: the days a part-timer does not work, the afternoon a teacher is at another site. The solver must never schedule into them, so they are hard.
Preferred free periods are wishes: the PPA morning someone hopes to keep, the early finish someone values. They are soft, honoured if possible. The two forms look identical in a spreadsheet column, which is exactly why they get confused and why the classification deserves an explicit pass.
Classify availability deliberately
Run this once per planning cycle, before generation.
- Collect every availability statement: contracts, duties, site splits, wishes.
- Mark as hard only what is contractual or physically true.
- Record everything else as soft preferences with weights.
- Map part-time patterns onto the actual teaching cycle, day by day.
- Compute common availability for every teaching team with a part-timer.
- Escalate teams whose common time looks too narrow before the solver discovers it.
How to do this in Smootables: unavailability rules
When this resource can’t be scheduled
J. Rivera · Availability rules apply school-wide across campuses.
Dates when unavailable (full day)
In-day time settings (repeating weekly)
Availability lives in Resources, under a heading that states the model plainly: when this resource can't be scheduled. Two rule types cover the cases: Dates when unavailable (full day) for absences and blocked days, and In-day time settings (repeating weekly) for patterns like every Monday before 10:00. Rules exist for teachers and rooms, they apply school-wide across campuses, and the add buttons are Add full-day block and Add in-day time rule.
The solver treats these as hard: generation schedules around them, and validation flags placements pinned into someone's blocked time before a run is attempted.
Containing the ricochet
The spread pattern is mechanical: shared classes need common free time, so each availability rule subtracts from every team the teacher belongs to. The containment is structural, not clever scheduling: fewer part-timers per team where staffing allows, team assignments checked against common availability before generation, and honest escalation when a team's window is too small.
When the same availability clash keeps returning at generation time, the fix is upstream: part-time teachers covers the staffing side, and the recipe walkthrough is teacher availability windows.
Questions planners ask about availability
Why does one part-time contract affect the whole timetable?
The sourced description is a ricochet: the part-timer's limited availability transfers to their whole teaching team, because shared classes need everyone free at once. Two part-timers in one team can only teach at their common times, which by itself may make the timetable impossible.
Should a teacher's preferred free morning be entered as unavailability?
No. Entering wishes as hard unavailability is over-hardening: it removes slots the solver may badly need. Record the wish as a soft preference so it can be honoured when cheap and traded when not.
Availability or workload cap: which is the binding limit?
Check both. A part-timer can be inside their hour cap and still be unplaceable because the available days are too narrow. The cap counts hours; availability decides which slots exist at all.