Who should read this: All PlaneConnection users, particularly crew members who operate in
connectivity-limited environments. Administrators should understand offline capabilities when
planning workflows and training. For a technical discussion of the platform’s data architecture,
see the Flight Operations Data Model explanation page.
Why Offline Matters for Aviation
Connectivity is unreliable in aviation for several structural reasons. Many Part 135 operations serve remote airports in Alaska, mountain regions, or rural areas where cellular and broadband infrastructure is limited or nonexistent. Crew members may need to reference trip details or review passenger manifests while airborne with intermittent or no satellite connectivity. Line service and maintenance activities happen on the ramp or in hangars where building materials and aircraft fuselages attenuate Wi-Fi signals. International operations face connectivity gaps between landing and reaching a terminal with network access. And even well-connected facilities experience ISP outages, router failures, and network maintenance windows. A platform that becomes unusable during these scenarios forces crews back to paper forms, spreadsheets, or memory — creating data gaps that undermine safety reporting accuracy and operational record integrity.How the Offline Queue Works
PlaneConnection uses a client-side mutation queue to handle operations performed while offline. The system follows an optimistic approach: you can continue working, and the platform synchronizes your changes when connectivity returns.Architecture Overview
How Changes Flow Through the Queue
When you perform an action while offline — submitting a safety report, updating a trip status, logging a fuel transaction — the system detects the lack of connectivity and routes the request into the mutation queue rather than sending it to the server. Each mutation is stored locally in IndexedDB with a timestamp, action type, payload, and unique mutation ID. The reason the UI updates immediately (an approach known as optimistic updating) is that waiting for server confirmation would make the platform feel broken during offline periods. You see the new report in your list, the updated status, or the logged transaction right away, even though it has not reached the server yet. When connectivity returns, the sync engine processes the queue in chronological order (FIFO), sending each mutation to the server as a standard API request. The server validates and applies each one successfully, removing it from the queue, or flags failed mutations for user review.Queue Persistence
The mutation queue is stored in the browser’s IndexedDB, which persists across page reloads and browser restarts. If you close your browser while offline and reopen it later with connectivity, the queued mutations will still synchronize.What Works Offline
Not all features are available offline. The following table summarizes offline capabilities by module:Safety Management
| Feature | Offline Capability |
|---|---|
| Submit safety reports | Full — reports queue and sync when online |
| View previously loaded reports | Read-only from cache |
| Attach photos to reports | Full — photos stored locally and uploaded on sync |
| Investigation updates | Full — status changes and notes queue |
| Risk assessment entry | Full — assessment data queues |
| SPI dashboards | Read-only (last loaded data) |
| Document viewing | Only previously cached documents |
Flight Operations
| Feature | Offline Capability |
|---|---|
| View trip details | Read-only for previously loaded trips |
| Update trip status | Full — status changes queue |
| Log duty time | Full — entries queue and sync |
| View crew schedule | Read-only from cache |
| FRAT assessment | Full — assessment queues |
| Expense entry | Full — expenses queue with receipt photos |
| Passenger manifests | Read-only for loaded manifests |
| Weather data | Not available (requires live data) |
| Real-time flight tracking | Not available (requires live data) |
FBO
| Feature | Offline Capability |
|---|---|
| POS transactions | Full — transactions queue |
| Fuel dispensing records | Full — records queue |
| Booking check-in/check-out | Full — status changes queue |
| QC inspection entry | Full — inspection records queue |
| Inventory counts | Full — adjustments queue |
| Customer lookup | Read-only for cached customers |
| Payment processing | Not available (requires payment gateway) |
Features that require real-time external data (weather, flight tracking, payment processing)
cannot operate offline. The system clearly indicates when a feature requires connectivity.
Conflict Resolution
When multiple users edit the same record while one or both are offline, a conflict arises at sync time. PlaneConnection uses a defined strategy to resolve these conflicts without data loss.Resolution Strategy
The platform uses a last-write-wins with conflict detection approach. Each mutation carries a version number reflecting the state of the record at the time the user made the change. At sync time, the server compares this version against the current record version. If versions match, the mutation applies cleanly with no conflict. If versions differ, a conflict exists and the server applies resolution rules based on the type of conflict:| Conflict Type | Resolution | User Action |
|---|---|---|
| Non-overlapping fields | Both changes apply (merge) | None required |
| Same field, same value | No actual conflict (idempotent) | None required |
| Same field, different values | Server version wins; offline change flagged | User reviews and re-applies if needed |
| Record deleted on server | Offline mutation becomes a create if applicable | User reviews the new record |
Conflict Notification
When a conflict is detected, the sync engine preserves both versions (server and local) in the conflict log and displays a notification to the affected user. A conflict resolution dialog shows both versions side by side, allowing the user to choose which version to keep or to merge values manually. The reason for preserving both versions rather than silently applying a default resolution is that in aviation operations, the “correct” value often depends on context that only the user can evaluate.Data Integrity Guarantees
PlaneConnection provides the following guarantees for offline operations:No Silent Data Loss
Every mutation in the queue is tracked with a unique ID, timestamp, and status. If a mutation fails during sync, it remains in the queue and the user is notified. Mutations are never silently discarded.Ordering Preservation
Mutations synchronize in the order they were created (FIFO). This ensures that sequential actions — such as creating a trip and then updating its status — arrive at the server in the correct order.Idempotency
Each mutation includes a unique ID that the server uses to detect duplicates. If a sync attempt is interrupted and retried, the server recognizes the duplicate mutation and returns success without applying it twice.Audit Trail Accuracy
Offline mutations carry their original timestamp (when the user performed the action) as a separate field from the server receipt timestamp. The audit trail records both times, ensuring accurate chronological records regardless of sync delay. For example, if a pilot submits a safety report at 14:30 UTC while offline and the device syncs at 16:45 UTC, the audit trail shows:- Action time: 14:30 UTC (when the pilot submitted the report)
- Server receipt: 16:45 UTC (when the server processed the sync)
Storage Limits
The offline queue uses IndexedDB, which has a storage quota managed by the browser. PlaneConnection requests persistent storage to prevent the browser from evicting offline data under storage pressure. Typical queue capacity supports thousands of pending mutations and dozens of cached photo attachments.Designing Workflows Around Connectivity
The most effective approach to offline operations is anticipatory rather than reactive. Operators who load trip details, crew schedules, and reference data before departing to low-connectivity areas benefit from richer cached data during the offline period. The system caches recently viewed data automatically, so simply reviewing upcoming trip information before leaving a connected area ensures that data is available offline. Timeliness matters even when offline. The reason PlaneConnection captures the original action timestamp (not the sync timestamp) is that data quality degrades with delay — a safety report entered minutes after an event is more accurate than one entered hours later from memory. Entering reports, expenses, and operational data promptly while offline preserves both accuracy and the correct audit trail timeline. Team training on offline behavior reduces confusion during connectivity transitions. Crew members who understand the sync indicator badge, the conflict resolution dialog, and the importance of not clearing browser data while mutations are pending will experience smoother transitions between online and offline states.Related
Flight Ops Data Model
How operational data is structured and stored.
Multi-Tenancy
Data isolation architecture that offline mode respects.
Submit a Safety Report
How to submit reports, including in offline scenarios.
Data Privacy
How offline data is protected and encrypted.