Events

An event is the container for a multi-aircraft show, mapping job, or training session: one site, one date window, a reserved fleet, an assigned crew, and its own checklists. It’s optional — a solo operator scheduling one flight never needs to touch it.

Events is a switch under Settings → Modules, and it depends on Scheduling being on. Turn Scheduling off and Events goes with it; turn Scheduling back on and your Events choice comes back exactly as you left it.

Reaching an event

Events appears in the sidebar under Operations and opens the Events view of the schedule board, which lists them. Click New event to start the create wizard. An individual event’s own page (its detail, layout, and live board) is a drill-in from there.

Reserving aircraft

Add aircraft to an event as reservations, individually or as a whole fleet group in one step — Fleet → Groups → Schedule as a unit starts the create wizard with every member of that group already selected. Each reservation has a flying / spare toggle: a spare stays reserved and visible on the event, it’s just flagged as not flying — useful when you bring backup airframes that might not fly. A flying reservation can be substituted for a spare if a plan changes on site.

Assigning crew

Crew attach to an event with an event role describing what they’re doing at the event, distinct from their day-to-day permission role or their flight-crew role on any one log:

Inventory — scan airframes in and out.
Inspector — run the pre-flight checklist.
Maintainer — maintenance tasks.
Battery / charging
Load-out
Pilot / PIC

Physical layout

For a show with a real field grid, the layout page (linked from the event) lets you lay out rows and slots and assign each airframe a position. It has two modes: assign an airframe to a cell, or select and claim a slice of cells (a row, a column, or any set of positions) for a task — so a crew can divide the fleet before splitting up to work it.

The layout page keeps itself current: other crew members’ claims and placements show up within a few seconds, without reloading. If a slot changed after you opened it, your assignment is refused and the page shows what the slot holds now; nothing is written over. The same goes for Edit on the event itself: if someone else saved a change first, your save is refused and your typed values stay in the form.

Scan to slot

On the layout page, Scan reads a drone’s tag or QR code with the camera, or takes the code typed in, and tells you its place on the field as Row R, slot S. It works in current browsers on phones and tablets, iPhone Safari included. The mobile app does not scan yet.

Assigned ahead of time. When each drone already has a cell (assigned while still in its case), a scan names the cell and highlights it on the grid. Nothing is changed.
Placed first, scanned row by row. Claim a row, then scan the drones in it. Each scan puts the drone in the next empty cell of your claim. Several crew can each scan their own rows at once. The layout’s Scan order decides which cell is next: Serpentine (snake), the default, runs row 1 from slot 1 and row 2 back from the far end, so you never walk back. Row by row starts every row at slot 1.
Wrong slot? Right after a scan places a drone, tap the cell it is really in to correct it.
A scan never moves anything by itself. Scanning a drone that already has a cell shows where it belongs. You can leave it there (carry it to that cell), or move it to this spot. If that cell already holds another drone, the two swap in one step. You are asked first, and told when the other drone was scanned in there, in case it has to be carried by hand.
After a scan you can run that drone’s pre-flight checklist in place. It’s optional; the next scan works straight away.

A scan that can’t be placed says why and changes nothing:

the code isn’t on any aircraft in your fleet;
the drone isn’t reserved on this event;
its cell is in another crew member’s claimed row (they are named);
you haven’t claimed a row;
every cell of your claim is full.

Changes from devices that didn’t apply

When a crew member’s phone is offline, it holds its changes and sends them later. If the event has moved on by then (someone else claimed the row, the event closed), the server refuses the change and the phone keeps it on its own Queue screen. Admins and owners see these at the top of the event page as N changes from devices didn’t apply: what the person tried, who, when, and why it was refused. Members and viewers don’t see the panel.

Mark handled removes the item from this list once you have sorted it out with the person. It only clears the list on the web; it does not change the event and does not touch the person’s phone, which still shows the change until they resolve it there. No notification is sent when a change is refused.

Starting flights

Start flight on the event creates one draft flight log per aircraft currently marked flying, linked back to the event. Aircraft already linked to the event are skipped, so clicking again does not duplicate them. A show with 20 flying airframes and 2 spares produces 20 drafts from one click. A draft is excluded from hours until you file it from Flight logs.

Live board

The event’s live board is a read-only, big-screen-friendly view of the field grid, colored by each airframe’s prep status. It’s an authenticated page, meant for a dispatcher’s own browser (or a TV signed into that browser) — not a link you’d share outside your org.

Checklists in context

Checklists tied to the event, to one airframe, or to a sortie run from the event page — no separate ID lookup. A Check all control lets you tick every item on one airframe in one action, which matters when you’re doing this dozens of times. See Checklists.

Closing an event

Closing an event warns you how many airframes aren’t confirmed packed out. The Pack-out section on the event page is where you confirm them, so wrapping up doesn’t quietly skip inventory.

What’s next

Run a checklist against an event or an airframe → Checklists
Who can do what at an event → Crew & roles
Link an event to the paid work it belongs to → Jobs