Handle diversions and conflicts
The exceptions queue, the conflict-resolution workspace, and the diversion console — three ways to work what's gone wrong.
- Start at Exceptions — the one prioritized worklist for everything that needs your attention: aging receivables, expiring documents, aging RFQs, tail/crew conflicts, crew currency, and your notifications, all in one place. Filter by severity or domain, group by domain, and work a row with Fix →, claim, snooze, or a note.
- When the item is a double-booking, open Conflicts instead — it lists every active tail/crew conflict and renders the two contesting legs side-by-side with their overlap window, so you can compare them before resolving.
- Pick a resolve action, for example pushing one leg's time. The reschedule is re-gated on the real engine — an FTL block, a grounded tail, or a persisting overlap comes back as the engine's real refusal, never silently accepted.
- When a leg diverts in flight, open Diversions. The active-diversions board shows tail/route, the divert airport, reason, note, status, and age.
- Record a divert on a leg with the reasons the backend offers — not a fixed list baked into the page — and walk it through its status lifecycle as it's worked.
- Check the passenger-notification chip on each row — Queued, Sent, Skipped, or Failed — before assuming passengers know their aircraft isn't landing where planned.
A diversion record is an operational fact, not a compliance verdict — and a notification chip never claims "delivered," only what the platform can actually confirm.