Index of everything the software does

It names which database is yours. It is not a trial limit and not a licence check you have to chase.

The four steps of the summer rollover: carrying rooms, lecturers and programmes into next year's university scheduling, and what is deliberately left behind.

Data, lecturer availability, generation, bookings, substitutions and reports — the whole timetable office with nothing to install.

One product, run from a browser or from the desktop program. The choice is made per school, over the same database.

CELCAT's modules one by one, and where the same job is done here — Pay Claim included.

Live, next year and a sandbox, each with its own menu slot, so nobody edits the wrong one.

Forty-five minutes against your own scheduling problem rather than a scripted tour.

Whether a school needs the desktop planner at all, and the one setting that decides which side owns the data.

Infrastructure in days, a first full cycle in weeks, and the stage that actually dominates the calendar.

From the installer to a working schedule: what to run, in what order, and what the server needs.

Who does what, in which weeks, between signing and a published schedule.

The keys that drive university scheduling without the mouse: the four view keys, the Alt jumps, and F12 to edit whatever is selected.

Both desktop editions install free from the Microsoft Store, into your own user profile, so a managed PC needs no administrator rights; Windows keeps them updated.

Bookmarked links, calendar subscriptions, foyer screens and the feed another department depends on. The half that is remembered in week one.

One key writes a password for every lecturer or group that has none, into a CSV that opens in Excel. Existing ones are left alone.

What the desktop application does when it cannot check in, and why it keeps working.

What transfers, what has to be rebuilt, and what should deliberately be left behind when you change scheduling system.

A real schedule in a browser, and the same one in the installer. Nothing to request first.

Classes and periods, or programmes and branches: five questions that tell you which desktop edition fits your week.

Elective selection, clinical placements, exam periods and exam registration, on the schedule’s own data and in the standard licence.

Scientia's vocabulary translated term by term, so an evaluation is about the software rather than the words.

TE Core, TE Reserve, TE Viewer: what each TimeEdit module is called here, and the three that need more than a word.

How long each stage of a first scheduling cycle really takes, from data to publication.

The full desktop application with a sample timetable. No key, no database and no form before you start.

Untis and WebUntis module by module, and the one difference that sends universities elsewhere.

Every import format documented in full, published free, so you can check the column layouts before committing.

CSV, Excel, a database view, the API or manual entry — and you can mix them in one installation.

Ready-made shapes for the usual cases, and a mapping step for a file that is yours alone.

Lecturers enter their own free hours in a browser; scheduling then runs against what they actually said.

A guided interface for institutions starting fresh, or for the parts an import never covers.

The order to do it in, so a first automated cycle does not depend on everything being ready at once.

What has to exist before course scheduling can run, and what can wait until the second year.

Two routes: student-level checking on the groups you already have, or building groups from an enrolment list.

A CSV export of your student records — numbers, names, groups, subjects — read with its columns recognised by name. Nobody is deleted.

One operation once the inputs are right, and what “right” means before you press it.

Place the hard sessions by hand, generate the rest around them. Neither mode locks the other out.

Specialities, hospital departments and the hours each placement owes: a rotation proposed week by week and handed to the schedule as lessons.

Merging cohorts into one class, with the room size worked out from the real total rather than by hand.

Room, lecturer, group, travel, contact hours, gaps — the rules course scheduling has to respect.

The distinction most tenders get wrong, with the practical test for which one a rule really is.

Choices handed to the schedule as groups with their students; once the groups are on their lessons, the generator keeps electives that share students apart.

Scheduling that runs against the free time lecturers entered themselves, not against a guess.

What each setting trades away, so a second run improves something specific rather than everything vaguely.

What the engine does with your constraints, in plain terms, and why they matter more than the algorithm.

How to find which rule is the one making it unsolvable, rather than relaxing all of them.

A lab split over three computer rooms, a lecture relayed to an overflow room: how the generator finds every room a lesson needs, together.

A clinic and its consulting rooms, a hall with a movable wall: a lesson in the whole takes every part.

One person, one minute, once — and then several planners work on the same schedule at the same time.

Induction, resits and summer schools before week 1, numbered backwards so that week 1 keeps meaning what it has always meant.

Compare variants on measured numbers instead of arguing about which one feels better.

Who holds what, how it is claimed, and why nothing pops up to ask you.

Where a group stops being a good approximation of a person, and what to do about it.

For one week, for a range of weeks or for good: the three places a lesson's room is changed.

Rollover, schedule build, timetable development: the same nine months under three names, stage by stage.

What to do when a lesson that needs several rooms was placed without all of them.

The whole cycle from structure to publication, and where the time actually goes.

What to do when a colleague still holds something and has gone home.

Why it is a hard constraint rather than a footnote, and how it is expressed.

Michaelmas fourth week, Revision, Induction — the institution's own name for a week, printed instead of the number.

A teaching week number is not the ISO calendar week. Where week 1 is, and why no client should ever compute one.

Optional: a request queue for the rooms that need one, direct booking for the rooms that do not.

Every date a repeating booking would fall on is checked against every room, lecturer and group first.

Every second week, the third Tuesday, the same date each month — what each one means and the trap in each.

Per room and per role, so self-service does not become a free-for-all.

Another faculty's lessons and bookings on the lecturers and rooms you share, shown in your own timetable and respected by the generator.

Tick Delete after reservation date and a one-off booking removes itself the day after its last date.

A room held by a booking still awaiting approval is not free. Why availability is a fact about the room rather than a view of the schedule.

By colour, by description, by date or by mark, counted and confirmed first, on Tools › Edit Reservations.

Deliberate overlap is normal. What matters is that the system records the clash as a decision rather than hiding it.

A proposal for every course’s exam dates in a period, every clash written out, and the rooms booked when it is published.

Students register for the published dates on their phones, within your deadlines and the student records’ own rules; the office overrides with a reason.

Seating, invigilators, limits per day and on consecutive days, and student-level clash rules across the whole cohort.

The registered students of one exam, with a column to sign and three empty lines; presence by the attendance code where the institution has attendance.

The constraints an examination schedule cannot break, and why they are stricter than teaching.

Who supervises, how many of them, and which desk each candidate sits at: the half of an exam timetable that is not when and where.

How many candidates each invigilator watches is the institution's decision, not a default in the software.

Holding the big hall for a conference in an academic year the database does not have yet, where everybody can see it.

Mark the bookings that should not follow you into the next academic year, or the ones that should, and one button does the rest.

The database names, the lecturer and room filters, and why the other databases have to be on the same server.

Rooms yes, lecturers and groups no — because a room is the one thing a year transition leaves unchanged.

Why one repeating room booking can become three, and what that means when somebody cancels it.

Staff reserve labs, meeting rooms and consultation slots themselves, inside the rights you set.

What to count, over what period, before deciding a building is full.

Two different numbers that get quoted as one, and the decisions each of them supports.

One booking, every week of a term, with the whole range checked before anything is reserved.

Why a seating plan belongs to the schedule rather than to a spreadsheet made the week before.

One address doing two jobs: a schedule anyone can read, and a booking system staff sign in to.

Cancel, move, substitute or teach it online — and whose time each one spends.

A rotating code shown in the room, reconciled against the schedule automatically. No hardware, no register call.

When the code is live, how long it lasts, and what happens to somebody who arrives late.

Rooms, lecturers and sessions changed by the office, with the effect visible immediately and no IT ticket.

In rising order of embarrassment, and which of them only student-level checking will catch.

Every clash surfaced the instant it is created, across room, lecturer, group and student.

Server-side tasks that email schedules, push changes, serve calendar feeds and refresh signage unattended.

Changing the lecturer on a session is not recording a substitution, and the difference shows up when somebody asks who actually taught it.

Finding who is genuinely free today, assigning them, and telling everybody in time.

Ask whether an exchange is possible before making it, instead of making it and reading the complaints.

The selection jumps to the first item that contains what you typed, accents ignored — in every list in the product.

The measures worth reporting when somebody says the load is unfair, and what they usually show.

Rooms, lecturers, programmes and courses kept; the schedule, the bookings and the student list dropped; the year advanced by one.

What a saved or cancelled booking sends and to whom, in the faculty’s words — one letter per recipient, and never at the booking’s expense.

One iCalendar feed each, written nightly for the whole year, so an address issued once keeps working all the way through it.

They look identical the day they are made. One keeps itself right and the other is a photograph of September.

A live feed a student's own calendar app follows, so a room change reaches them without an app.

Only the people a change actually affects are told, which is what keeps anyone reading them.

Screens driven from the live schedule rather than from a playlist somebody has to remember to update.

A link, an embed, a calendar subscription or an app: what each is good at, and which of them can tell anybody about a change.

The school’s own mailbox in the From line, or only a reply address: who timetable letters come from and where the answers go.

Personalised timetables and change notices sent from the application, to a programme, a year or one person.

Sending through smtp.office365.com, why SMTP AUTH is often switched off, and what changes at the end of December 2026.

A Teams, Zoom or Meet address on the room, the subject or the single lesson, so the class joins from its timetable entry.

On the session in the timetable, not in an e-mail sent in week one.

On the room, on the subject, or typed onto a single lesson — and what each of those choices means.

Which address wins when a lesson carries more than one, set per programme because faculties disagree.

The timetable of a lecturer or a room as a calendar subscription that Outlook keeps current by itself.

Printed and exported schedules with the layout and content you choose, not a fixed template.

Why a calendar feed cannot originate a message and a push notification can. Publishing is not notifying.

Answers to the timetable office rather than to us, with no password and nothing to set up anywhere else.

Entrance, corridor, lecture room and library each want a different view of the same schedule.

A link, an embedded view or your own page against the API — three ways, one live source.

One real letter to yourself first, before three hundred lecturers get it.

One letter per lecturer with their own week attached, in their own language, written and scheduled by the school itself.

Two clicks from an empty slot on the week you are already looking at.

This week’s department and its address, the mentors, the hours so far against the hours owed, and the whole rotation.

On the phone, with when each elective is taught and what it clashes with in the student’s own week; ranked or first come.

Function keys that switch straight to the tutor, room, group, course or student view for whatever is selected.

Signing in adds booking and reports to the page a lecturer was already reading.

Staff sign in with the account they already use for Outlook and Teams — single sign-on, no second password. The steps, and Microsoft’s one-time set-up.

Native iOS and Android, personalised, free for everyone at the institution, with push notifications.

The administrator defines what is on offer, students choose in a browser, and the office gets every choice back as a spreadsheet.

Students use the institution's own account, so there is no separate password to issue, reset or remove.

What a student can do with their own schedule once they have found it.

Not approved yet, no lecturer with that address, a guest or a personal Microsoft account: what the sign-in page says, and what to do.

Five ways to fit a week onto a phone, and when each of them is the right one.

How a student narrows the institution's schedule down to their own, with no account at all.

Why a report generated from the live schedule answers a question a monthly export cannot.

The figures that show a second run was actually better, rather than differently arranged.

Hourly rates per lecturer and per kind of teaching, and the report that turns a term of teaching into figures accounts can pay from.

Room usage, staff load, unallocated sessions — the four or five that get requested every year.

Utilisation, workload, unallocated sessions and custom reports, in the browser or exported.

Frequency, occupancy and the seats nobody sits in: why a survey usually confirms what the timetable already knows.

Every endpoint, parameter and error, published free so a developer can judge feasibility before a meeting.

Schedules, rooms, lecturers, groups and courses, in one request per view rather than a chain of them.

A public endpoint that answers without credentials, so the first evaluation costs nobody a phone call.

Booking through the API is done by a person signing in as themselves, never by an application account, because the schedule records who booked it.

The operations that are not read-only, each of them off unless an account is explicitly permitted to use it.

Sections and CRNs mapped field by field to rooms and weeks, in the form names a registrar's office works in.

Enrolling in a unit and choosing which classes to attend are two steps, and the timetable has to treat them as two.

Both are supported and both are ordinary; the choice is about your policy, not our architecture.

Separate schedules that stay separate, and see each other where they have to.

When two faculties run different hour patterns and a shared lecturer teaches in both.

The Colleague forms a timetable reads and writes, in the four-letter mnemonics people actually say.

What a failed API call tells you, and why that matters more than the status code.

SSO for staff with Microsoft Entra ID (formerly Azure AD): one approval by your Microsoft 365 administrator, two settings, addresses that match.

A dictionary that maps one faculty's spelling of a room or a course onto another's.

Catalogue and schedule in two layers, joined by the Associated Class that says which sections go together.

Files, an API, or scheduled synchronisation — and the questions that decide which one you want.

Microsoft Entra ID for staff, Shibboleth and comparable federated identity, so nobody keeps a second password for the schedule.

Where the line between SITS and the timetable runs, in the record names your SITS team uses.

Further education counts learners and is funded on a return, so the register the timetable carries is money.

What a learning platform can do with a personal calendar feed, and the plugin we do not publish.

The decision to make before any integration work: one owner per kind of data, written down.

Workday splits the course into three objects, and the split is exactly where the timetable's boundary belongs.

The signed certificate, downloadable, from a UK-based certification body.

What you get at any price point, because there is no feature tier to be upsold out of.

Priced per independent schedule rather than per student, per room or per module.

Sign-in and basic profile only, no Microsoft Graph token; passwords, MFA and Conditional Access stay at Microsoft. For the security review.

Exactly what the app sends and what it keeps locally. No advertising and no tracking.

What is held, on what legal basis, and who the controller is when your institution runs it.

Read sideways, a timetable is a record of where several thousand named people are required to be. What it discloses about staff and students.

Size, complexity, campuses, integrations, hosting, service level, support hours, development and the market you buy in: the nine things every quotation is built from.

What we need to know to price it, and what comes back.

Eight institutions, from Oxford to Klaipėda, in their own words: excerpts from the reference letters they signed in autumn 2026.

A checklist you can lift into a tender document, written so it does not describe only us.

The one that separates a scheduling engine from a system your office can actually run.

Public versus internal views, a genuinely private note on a booking, scoped credentials and a named list of permitted sites.

The obligations behind the badge, as opposed to the badge.

Data residency, hosting location and the parts of that decision that stay yours.

The questions institutions ask first, about rollout, scale, platforms and support.

Screenshots of the week grid, lesson editing, day views, courses, groups, rooms, generation and reports in a browser.

Screenshots of the desktop program: views, generation settings, constraints, conflicts, exams and reports.

The free apps and the corridor-screen designs, screen by screen.

The booking form, the availability check, approvals and booking rights.

The published timetable students and staff read: filters, class details, view modes and the school's own settings.

Every screen we publish, in five chapters: the browser administration, the web timetable, room booking, the mobile apps and info screens, and the desktop application.

Module or course or unit, session or class or activity: the same thing in the words each country uses.

Electives, placements and exams: a guide for the student office, the students and the examiners, the newest in English, Slovenian and Croatian.

Every manual we publish, free and ungated, including the 278-page desktop reference.

What actually changes between a university, a college and a multi-campus institution.

The comparison stated on mechanism rather than on adjectives.