Campuses, sites, classrooms, resources, multi-room
This page brings together the organizational and physical modeling of a school in Omniscol: which campuses structure the classes, where lessons take place, in which classrooms, with which movable equipment.
Campuses — the organizational level
A campus distinguishes several locations, faculties or divisions within a single account. It is an internal organization concept: it groups classes according to the structure of the school and makes certain filtering easier.
This concept is optional. It becomes most useful when the site concept does not match the logical organization of the school well, or when you want to keep both in parallel.
The campus cuts across sites. A site describes a geographical or physical reality: location, time grid, classrooms, travel times. The two concepts do not necessarily overlap. That is precisely when they become most useful. For example:
- a faculty can use several sites;
- a physical site can host several campuses or divisions;
- several faculties can share the same buildings;
- several schools in a group can share several sites in a criss-cross pattern;
- a campus can serve mainly as an analysis filter, without changing travel times.
Even when campuses and sites overlap almost completely, keeping both can remain useful for filters, groupings and certain analyses.
Campuses are created in the general settings, below the class levels. They can then be set on classes. The conflict diagnostic can use them to filter alerts by organizational scope.
Sites — the geographical level
Each site represents a distinct physical or geographical location. At least one site is required.
If all your lessons take place in the same location, create a single site. If your school is multi-site with instructors or students who move around, create as many sites as needed and enter the travel times between them.
Each site carries its own time grid (slot start/end times, breaks, lunch, closures) — sites can have different grids (for example a main building and a satellite location with different hours).
Multi-site setups are a common practice in higher education (multiple campuses, regional branches), but also in primary and secondary education (a middle school + a high school in the same school group with separate buildings, a school with a preschool annex, etc.).
Multi-site is not included in the Lite plan. It is available from the Standard plan upwards.
Multi-site: policy and travel times
Typical case: a teacher finishes a lesson on site A at 10:00, must be at site B at 10:30, and the trip takes 15 minutes. On a time grid with a 30-minute break between lessons, this works. With only a 10-minute break, it does not fit.
Entering travel times
On the Sites screen of the Timetable management module, the Distance between sites button opens a popup that presents travel times as a triangular half-matrix: N sites = N×(N−1)/2 cells to fill in (no diagonal, no duplicates — the matrix is symmetric). Enter the durations in minutes for each pair, then confirm with Save. Without this input, the solver assumes that no travel is needed between the sites — it may teleport teachers, which obviously does not work in practice.
Teacher policy: automatic site changes
A teacher can change site automatically from one lesson to the next — the algorithm handles it. There is nothing to declare on the teacher side: the inter-site travel times just need to be entered.
Class policy: default site + manual override
A class is attached to a site by default (its enrollment site). All its lessons take place on this site by default.
But you can manually attach a classroom from another site to one of the class's lessons — for example "PE lesson in the annex gymnasium". In that case:
- the preassigned classroom is kept by the algorithm (it does not try to replace it with a classroom from the default site);
- the solver computes the travel times relative to the lessons before and after (based on their site: the class site by default, otherwise the site of the classroom forced on those lessons).
If no classroom is specified on a lesson, the algorithm picks a classroom from the class site. This is the default behavior.
A blocking constraint, to the minute
The inter-site constraint is blocking in the automatic generation algorithm. If even one minute is missing between the end of a lesson on one site and the start of a lesson on another site, the placement is rejected — there is no automatic relaxation.
The check is precise on the effective time grid: if two slots follow each other with a 15-minute recess and the trip takes 10 minutes, it fits; if the trip takes 16 minutes, it does not.
Lunch break on a site change
When a site change falls on the lunch break, the travel time is subtracted from the actual lunch time available. The algorithm takes a minimum lunch duration into account for teachers and for students (set per site); if the trip reduces this time below the minimum, the placement is rejected.
Practical consequence: declaring travel times and per-site lunch durations correctly avoids timetables that are theoretically valid but physically impossible to follow.
Impact on the diagnostic
If you see "impossible" on multi-site placements, check first:
- the declared travel times (no teleporting, no absurd overestimates),
- the breaks between lessons on the time grid,
- any lunch break on the slot concerned,
- the preassigned classrooms: if a class has a classroom forced on another site, that classroom sets the constraint.
In manual placement, the constraint appears in orange, and you can always force it. But unless the lessons are locked, running the automatic generation algorithm afterwards will move the lesson(s) to resolve this conflict.
Use case: off-site activities
Beyond permanent campuses, the multi-site mechanism naturally covers recurring off-site activities:
- hotel or restaurant visits for a hospitality / catering school;
- museum or workshop visits for an art or design school;
- recurring company visits (work-study visits);
- field work on an external site (construction site, farm, partner laboratory).
Create a dedicated site for each recurring external location, with its travel time from your main site. The blocking constraint applies as usual: if the trip does not fit in the time available between two lessons, the placement is rejected.
Going further: higher education
Multi-site setups are especially common in higher education (multiple campuses, regional branches, instructors moving around). Specific cases (one timetable per site thanks to multiple active timetables — included in Premium —, virtual sites for videoconferencing, etc.) are covered in Multi-site in higher education.
Classrooms — the premises
Classrooms are attached to a site, which carries their physical reality: location, time grid, travel times. A classroom carries:
- a name,
- a capacity (number of students; a critical field for the solver),
- optionally a specialisation (free label: chemistry, computing, sport…),
- optionally a maximum number of simultaneous classes, for the large rooms able to host several lessons in parallel (exam room, gymnasium, swimming pool, outdoor space); this field only appears once a specialisation is set,
- optionally free tags or comments,
- optionally a building,
- optionally specific opening hours.
Multi-room: one lesson in several classrooms
Omniscol supports assigning several classrooms to the same lesson.
Use cases:
- Exams split across lecture halls — a 200-candidate exam spread over three lecture halls (capacity 70 + 60 + 80) with a single instructor in charge. The total capacity is computed as the sum of the assigned classrooms.
- Broadcast lecture — a lecture in a main lecture hall, streamed by videoconference to a satellite room (on another site, or even to a fully remote cohort).
- Split practicals — a practical session of 30 students spread over two neighboring rooms (15 + 15) with the same teacher moving between them.
Limitation: if the sum of the capacities remains below the group headcount, Omniscol displays a conflict. It is up to the administrator to decide how to resolve it (by adding a classroom, reducing the group, or accepting the conflict if it is deliberate — for example, when you know that not all enrolled students will attend).
Classroom specialisations
Specialisations (chemistry, computing, sport, gymnasium, multimedia, supervised-study room) are optional free labels defined by the school. You create the specialisations that match your naming scheme, to single out certain rooms that are dedicated to specific lessons (a gymnasium for sport, a swimming pool for swimming, a laboratory for a chemistry practical, etc.).
The solver strictly respects specialisations: if a subject requires "chemistry", only the classrooms carrying exactly this specialisation will be used.
Each classroom carries at most one specialisation. For a room shared between two specialised uses, use an umbrella label (for example "computing-multimedia") and associate this same label with the subjects concerned. See Classroom specialisations.
Classroom dedicated to a class
Many primary/secondary setups associate a classroom with each class (lessons take place there by default, only the teachers move). This is configurable on the class — the engine then prioritizes this classroom for the class's lessons (with a priority higher than the teacher's preferred classroom, if one is defined).
Classrooms in two virtual sites
If you have two virtual sites for a single physical location (typical of a middle school + high school sharing the premises), a classroom can only belong to one site at a time. To make it usable in both contexts, duplicate it in both sites and enter exclusive opening hours ("free in the morning for the middle school, in the afternoon for the high school") to avoid double bookings.
Resources — movable equipment
A resource is a piece of movable equipment not attached to a particular classroom: three portable projectors, a case of tablets, a microphone kit, etc.
Each resource carries:
- a name,
- an available quantity (the case counts as 1, not 30 — enter the number of cases, not individual tablets).
The solver guarantees that on any given slot, the number of lessons requesting the resource does not exceed the available quantity. There is no point in modelling resources you "always have enough" of — do it only for real shared limits.
Special case — videoconferencing and per-course links
The format of a lesson — in person, remote, hybrid or self-study — is carried by its modality (Premium): it determines whether the lesson uses a physical classroom. For a remote or hybrid course, you can attach a videoconference link to the course (Zoom, Teams, Meet…). See Videoconference links per course.
This is finer-grained than the videoconference link on the class, which is a general default link on all its lessons.