Release note 18/09/2026 - Prerequisites, aircraft model certificates and multiple ground instructors

Want the quick version? Watch the short videos under each feature below for a quick walkthrough of what’s new and how it works.

What's new

1. Scheduling: Aircraft model certificates — stop uncertified instructors and crew being booked on a model
2. Scheduling: Prerequisites — lock sessions behind other sessions, minimum hours and role-based certificates
3. Insights: Control which Business Insights widgets each role and user can access
4. Calendar: Planned duty, actual duty and leave on the calendar
5. Duty time: Administrators can stop a forgotten duty timer
6. Students: Instructors can write instructor notes on a student profile
7. Reporting: Students can download their own Pilot Training Record
8. Ground: Multiple ground instructors on one lesson
   
   

This release is about putting your training rules into the system instead of into people's heads. Until now, a great deal of what keeps a training organisation compliant has lived with your staff: knowing that a student cannot fly Nav 2 before Nav 1, that an instructor is not current on the type they have just been rostered to, that a class was really taught by two people, or that someone's duty timer has been running since Tuesday.

Each feature below takes one of those judgements and moves it into FlightLogger, where it is applied consistently, visible to the person who needs it, and recorded for your auditor. Prerequisites and aircraft model certificates stop non-compliant registrations before they are made. Multiple ground instructors and the new calendar layers make your records match what actually happened — which also means your invoicing does. And the Business Insights permissions, instructor notes and self-service PTR download all do the same quiet thing: give the right people access to what they need, without making an administrator the bottleneck.

Everything here is either off by default or additive, so nothing changes for your account until you turn it on — with one exception, noted under the calendar section.

 

Aircraft model certificates

FlightLogger can now prevent a booking where the selected flight instructor or crew member is not certified for the selected aircraft model.

From Administration → Aircraft models, each model row carries an aircraft icon leading to its Certificate requirements page. There you attach one or more certificates to the model — a type rating, a differences course, a company check. From then on, every assigned instructor and crew member must independently hold a current certificate of every required type before the booking can be saved.

What the scheduler sees

By default, the invalid combination stays visible and is marked with a red blocking issue — the same pattern you already know from scheduling a ground session with a student who is not active on the program. The booking cannot be created or saved until the issue is cleared.

If you would rather not see invalid options at all, a new setting under Administration → Account settings → Booking → Business rules called "Use aircraft-model certificate requirements as booking filter" hides ineligible aircraft models, instructors and crew from the selectors instead. It is off by default.

Prerequisites: sessions, minimum hours, certificates and overrides

 

You can now define what a student must have done, flown, or held before they are allowed to proceed with a session — and what an instructor must hold before they are allowed to teach it. Prerequisites apply to combined syllabus programs and flight training programs, and can be attached at program, program revision, or at session level.

A new Prerequisites area sits alongside Requirements in the program builder, with three tabs: Sessions, Hours and Certificates.

Prerequisite sessions

Mark one session as a prerequisite of another — Nav 1 before Nav 2, a ground session before the flight session it prepares for. You can also tick a single option to force an entire program to be completed in chronological order, which is inherited automatically by all of its revisions. Where a student is not yet eligible, the proceed control is replaced by a padlock; clicking it opens a pop-up titled "This session is currently blocked" explaining exactly which prerequisite is missing.

Minimum hour requirements

Set a threshold a student must reach before proceeding — for example, 5:00 VFR on a solo navigation session, or a minimum number of ground hours in a specific subject or in total. The block pop-up shows both the requirement and the student's current figure, so the shortfall is immediately clear.

Requirements are additive across levels. If your program requires Company Induction of instructors and the session "IFR Lesson 1" additionally requires IRI Rating, an instructor must be current on both to teach that session — holding the program-level certificate does not waive the session-level one.

Pending certificates

Users can now see certificates they will need before they become active. A new Pending certificates section on the user profile, under Certificates, lists every upcoming prerequisite, states why it is required — "Required by: Session: …", "Required by: Program: …" — and lets the user or your staff upload the document in advance. No more scrambling the week a requirement bites.

Instructor blocking on aircraft and classrooms

An instructor with an unresolved prerequisite has their name shown in red on an aircraft or classroom booking, exactly as a student who is not active on a program is shown today. Hovering explains why — "The instructor has unresolved prerequisites on [session name]" — and the scheduler cannot create the booking without removing them. Only the person's name is marked, never the aircraft or classroom.

Override requests and audit log

Real operations need exceptions, and exceptions need paperwork. From any blocked session a user can submit an override request with a written reason. The session stays blocked until someone decides — submitting a request does not unblock anything on its own. Requests land in a new Override requests area under Warnings, where an authorised user accepts or declines; acceptance unblocks that one session for that one student.

Access is controlled by a new designated user role, Override manager, under Administration → Account Settings → Designated User Roles.

Every request is written to an audit log: who requested it, the reason given, the date and time it was raised, and when it was accepted or declined and by whom. The same override and audit mechanism covers all prerequisite types — sessions, hours and certificates alike.

Note
Prerequisites apply to combined syllabus programs and flight training programs. They do not apply to legacy theory programs or pure LMS theory. Prerequisite certificates always hard-block, which is what separates them from the existing certificate requirements under Requirements — those continue to work exactly as before.

Control who can see which Business Insights widgets

Until now, which Business Insights widgets a user could choose from was fixed by FlightLogger, and most were restricted to administrators. Several of you have asked for a way to give a non-administrator access to a specific insight without promoting them to administrator — which is exactly what this adds.

The user permission area gains a new Business Insights Module (BIM) section headed Widget access, using the same widget picker you already know from the front page. You decide which widgets a role may access, and you can override it for an individual user where you need to. If a user holds several roles, they get the sum of the widgets granted to those roles. Each user still chooses their own front-page layout from whatever they have been granted.

There is also a reset control that returns widget permissions to their defaults, with a confirmation step before anything changes.

Note
Existing access was preserved on release — every role kept the widgets it already had, so nobody lost a widget from their front page when this went live. You only need to visit this area when you want to grant something new.

 

Planned duty, actual duty and leave on the calendar

The user calendar gains three new layers alongside the duty records you already keep.

Planned duty

Every booking a user is assigned to now appears as a duty interval on their calendar. It is live: move the booking and the planned duty moves with it; cancel the booking or remove the user and it disappears. Planned duty is shown for information — it is not billed.

Actual duty, and approving it

Work that actually happened — a flown flight, a completed lesson or ground activity — appears as its own layer, derived from the registration it produced. It is read-only: corrections are made on the underlying activity, not on the calendar.

Clicking an actual duty approves it; clicking again un-approves it. Users approve their own, and administrators can approve on their behalf. Once approved, it becomes an ordinary duty record — billable, counted in the duty report and in flight and duty time totals, and editable like any manually entered duty.

Leave

Availability gains a third option: available, unavailable, or leave. Leave behaves exactly like an availability — same self-service permissions, recurrence, comments and changelog — and counts as unavailable everywhere availability is evaluated, so it takes precedence over an overlapping "available" entry. It is drawn with the unavailable fill plus a yellow dotted border so you can tell them apart at a glance.

Booking someone inside their leave shows the warning "[User] is on leave during the selected period" with an explicit confirmation. The person saving can still go ahead — operations sometimes require it — and the override is recorded with who did it, when, which booking and whose leave. A user on leave who is assigned to a booking also appears in the Conflict Center automatically.

Note— visible change for every account
The change to overlapping calendar entries applies to all accounts and to all existing event types. There is no opt-out. Nothing is lost — overlapping entries are simply drawn beside one another rather than filling the day.

 

Stop a forgotten duty timer

When someone forgets to stop their duty time, it keeps accumulating — and a single forgotten timer can produce hundreds of phantom duty hours and a flood of meaningless limit warnings. Administrators could already edit duty records after the fact, but they could not end a duty session that was still running.

Now they can. On a user's profile, in the status section, "On duty" becomes a clickable button for administrators. Clicking it stops and submits the user's duty time, after a confirmation, and the status updates to Off duty. The change is reflected in the Availability & duty time calendar view.

Enable it under User Permissions "Duty time". Existing accounts have it off.

Note
This requires the Flight and Duty Time Limitations module. It only ever stops duty time — an administrator can never start duty time on someone else's behalf, and the button does not appear for a user who is already off duty.

Instructors can write instructor notes

Instructors can now add and edit the Instructor note on a student's profile — the kind of context that is genuinely useful to the next instructor who flies with that student, and which previously had to be passed to an administrator to type in.

Enable it at Administration → Account Settings → User settings → Miscellaneous. It applies to both flight and ground instructors, and the note is edited where it always has been, under the student profile. 

The permission is deliberately narrow. Turning it on grants access to the instructor note field and nothing else — no other student information becomes visible or editable, and admin notes remain hidden from instructors entirely.

 

Students can download their own Pilot Training Record

Students on a program that uses the PTR can now generate and download their own record as a PDF, from the report generator on their own profile — without asking an administrator.

This removes a steady administrative load from your staff. Every time a student wanted their record — to check progress, to bring to an examiner, or simply to keep — someone had to generate it and hand it over. Now they do it themselves, and the output is the same PDF your administrators generate today.

Note
Access is determined by whether a PTR exists on the program, not by country. Because the PTR is a Canadian instrument, this affects only clients whose programs use it. It cannot be switched off at school level — a school that could revoke a student's access to their own regulated record would risk falling out of compliance.

 

Multiple ground instructors on one lesson

You can now assign more than one instructor to a single ground or theory lesson, in both the booking and the registration. This reflects how theory training is actually run: large group classes, sessions where several instructors supervise, assess, or grade (KSA 100, for instance), and lessons where teaching and evaluation are split between people.

A new "+ Add instructor" button works exactly like "Add crew" on flight operations. The existing Instructor field is the primary instructor and is always listed first; anyone added afterwards is an additional instructor. It is available on all six ground booking types: Class theory, Progress test, Theory release, Exam, Type questionnaire and Extra theory. Additional instructors block their own time slot just like crew, so double-booking is caught.

Who can do what

• The primary instructor adds, edits, submits, and signs off the registration.
• Additional instructors have view-only access — they see the lesson, the full class list and their co-instructors, but cannot edit, submit, proceed or cancel. Proceed and Cancel are hidden from them on the booking widget.
• The booking still appears on an additional instructor's front page and calendar, so they always see what they are teaching.
• Sign-off always routes to the primary instructor, who receives the signature-missing prompt even when someone else submitted the registration on their behalf.

New setting

General Settings → Registrations → "Allow primary instructor to add/remove additional instructors"

This is switched off by default and an administrator has to enable it deliberately. The reason is payroll control — adding an instructor to a lesson has a financial consequence, so by default that stays under administrator oversight. With the setting off, existing additional instructors remain visible as read-only names; only the add and remove controls disappear. Administrators keep control regardless.

Where the data now follows

• Changelogs — all instructors on Ground training, one per line on screen and comma-separated in XML and CSV.
• Activities pages — an "Instructor(s)" column showing everyone, including "Export as".
• Cancellation report — the "Pilot" column is now "Pilot/Instructor(s)" and lists every call sign, in all export formats.
• Invoice report → Expenses — each instructor gets their own row with their own class time, so per-instructor invoicing is correct.
• Raw data – theory report — all instructor call signs, with instructor ID, CAA reference and user reference populated for each.
  
  

Coming next week: a clearer view of student progression

Next week, we are introducing an improved Student Progress view across flight, ground and combined syllabus programs.

For combined syllabus students, progress will be split into Combined, Flight and Ground, each with its own completion percentage, pace and status. The progress graph follows the selected view, making it easier to see not just how far a student has progressed, but whether their flight or ground training is keeping pace.

Additional improvements

Alongside these features, this release includes a number of smaller refinements and fixes across the areas above — reporting and export consistency, calendar rendering and permission handling in particular. As always, if anything here does not behave the way you expect on your account, please get in touch with support and we will take a look.

Best regards,
Team FlightLogger