Data organization: subjects, teachers, classes, timetables

Omniscol distinguishes two levels of organization: a school repository carried by the Administration module (subjects, users, school years…), which describes your institution over the long term, and timetables that draw on its elements to build a consistent plan over a given period. Understanding this duality is the key to handling changes calmly (renaming a subject, updating a teacher, archiving a timetable) without breaking the history.

Overview: two levels, two logics

School level: a global repository with a long lifespan, managed in the Administration module. It contains what is true for the institution independently of any particular timetable — the calendar of school years, the subject catalog (subjects common to the country plus the school's custom ones), and the directory of users (with their roles).

Timetable level: a consistent plan over a period. Each timetable has its own list of teachers, classes, groups, subjects attached to classes, and lessons. These objects are not mere references to the school repository: they are local copies, which can be enriched without modifying the repository. Conversely, the school-level repository can evolve (subjects or teachers being deleted) without breaking past timetables.

The rest of this page details each type of link.

The school year: the time frame

The school year defines a start date → end date range and the list of holidays (see School year). It does not directly "contain" timetables: it is the timetables that unfold over weeks (weekly / cycle mode) or dates (calendar mode) belonging to a school year.

This allows several configurations:

• A single timetable per school year (the standard case): the timetable covers all the working weeks of the year.
• Several successive timetables within the same year: one timetable per term for example, each handing over to the next at the changeover dates.
• Several timetables in parallel over the same period (feature included in Premium; on some Standard accounts it can be enabled under a suitable contractual arrangement), for example:
  • a timetable for the recurring core curriculum
  • a calendar timetable for masterclasses, merged when viewed.

See Multiple active timetables in parallel.

The school year therefore remains a frame — not a container. Changing its start and end dates or its holidays updates the calendar used by the timetables attached to it, without modifying their content.

Subjects: from the school catalog to a class's lessons

Level 1 — The catalog in the Administration module

At school level, two origins coexist:

• Common subjects: Omniscol's reference set for the configured country (official codes, standardized labels). This catalog is read-only for the school.
• Custom subjects: what the school creates itself, managed from the Subjects screen. Each custom subject has a name, a (short) code, and optionally: a short name, a specific color, a parent subject, a family.

This catalog says nothing about which classes teach these subjects — it only says that they exist.

Subject families can also come from a shared per-country reference set, read-only, or from a custom reference set local to the school.

Level 2 — Assignment to a class (with or without a type)

When you assign a subject to a class in a timetable, a local copy of the subject is created in the class, enriched with planning-specific fields (target number of hours, pedagogical weight, incompatibilities, default teachers, classroom specialization…).

If you assign the subject with a course type (Lecture, Tutorial, Lab, Exam — see Types of course), each type creates a separate entry in the class:

This is intentional: each variant (Mathematics lecture, Mathematics tutorial) becomes a separate local copy, with its own number of hours, its own teachers and its own incompatibilities. The link with the catalog is not a hard dependency: the local copy keeps the subject's origin as long as the subject still exists in the catalog. If the subject is deleted from the catalog, the local copies in the timetables remain valid.

Level 3 — From course settings to lessons

In Omniscol, what is commonly called a course generally corresponds to a subject assigned to a class, possibly associated with a course type (Lecture, Tutorial, Lab…), then enriched with planning information: number of hours, teachers, groups, placement constraints, classrooms or resources.

This definition states what needs to be scheduled. Lessons are the occurrences actually placed in the timetable, on a given week or date.

Example: a class subject such as Mathematics [Tutorial] can define a number of hours, teachers, groups, placement constraints and classroom preferences. Lessons are then created from this definition. See Courses, lessons, course types.

Teachers: school repository → enriched timetable copy

The teacher at school level

At school level, a teacher is a user holding the teacher role (the same user can hold several roles — see Users and roles). Managed from the Teachers screen, this user record carries the durable identifying information: last name, first name, login, email, identification number, as well as the teacher's global availability (recurring) and reference service hours.

The teacher assigned to a timetable

When you assign this teacher to a timetable, Omniscol creates an enriched partial copy in the timetable. The copy carries over only a selection of fields from the school repository and adds planning-specific fields to them:

This duality matters: the same teacher can have different service hours depending on the scope being planned, or a different preferred classroom at a given time (for example because of a temporary disability).

For availability, the logic depends on the planning mode:

• in recurring mode, the availability entered by the teacher goes through an acceptance phase by the administration. It can be adapted locally in the timetable, for example by turning a strict unavailability into an undesired time slot;
• in calendar mode, the teacher's availability is treated as a single source of truth, in particular for external instructors. It can be viewed and edited from the user's record or from any calendar timetable the teacher is assigned to.

In both cases, some settings remain timetable-specific and can locally enrich this availability.

Virtual teachers

A variant: you can create a virtual teacher in a timetable — a position to be filled, with no real user behind it ("the future math teacher"). It has no counterpart at school level. At recruitment time, you can replace this virtual teacher with a real teacher user (see Assigning teachers to a timetable).

The local-copy principle, in summary

The same logic governs subjects in a class and teachers in a timetable: a local copy is created at assignment time, and it is this local copy that carries the timetable-specific fields.

Why this design choice:

• Temporal independence. A timetable closed last year must not change when you rename a subject or a teacher this year. Local copies guarantee historical integrity: what was planned stays exactly as it was at the time.
• Contextual enrichment. A teacher does not have the same availability or the same service hours depending on the scope being planned; a subject does not have the same weight or the same incompatibilities depending on the class teaching it. The local copy is the natural place to carry these variations.
• Cleanup without breakage. Deleting or overhauling a subject at school level does not erase the timetables that used it — their local copies remain valid.

As a trade-off, school-side renames do not propagate silently everywhere. That is the subject of the next section.

Practical consequences: renames, deletions, history

When you modify an entity at school level, Omniscol applies a clear propagation rule:

The distinction between "past" and "current or future" is made against today's date: a published timetable whose last active week is before today is considered past and is no longer modified by renames.

When to propagate manually

Automatic propagation stays deliberately narrow: subject name, code and color; teacher name and identifier. The name and code of a locally copied subject cannot be edited in the timetable; only its color can be redefined locally. The other fields (incompatibilities, pedagogical weight, service hours, per-timetable availability…) are not synchronized, because they are by nature timetable-specific.

If a deeper change must be applied to several existing timetables (for example: revising a teacher's service hours on all active timetables, or adding a new subject incompatibility everywhere), you have to act timetable by timetable. For bulk operations, the fastest tool is the copy-paste import from a spreadsheet on the relevant screen of each timetable.