> ## Documentation Index > Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt > Use this file to discover all available pages before exploring further. # Offline Mode and Data Synchronization > How PlaneConnection handles offline access, mutation queues, sync on reconnect, conflict resolution, and data integrity for aviation operations. Aviation operations do not pause when connectivity drops. Pilots file reports from remote airstrips with no cell coverage. Dispatchers update trip details during satellite internet outages. Line service technicians log fuel transactions on the ramp where Wi-Fi does not reach. For an aviation platform to be genuinely useful, it must work when the network does not. This page explains how PlaneConnection handles offline scenarios -- what works without connectivity, how changes queue and synchronize, how conflicts are resolved, and what guarantees you can rely on. **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](/en/explanation/flight-ops-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 ``` ┌─────────────────┐ ┌──────────────────┐ ┌──────────────┐ │ User Interface │────►│ Mutation Queue │────►│ Server │ │ (reads cached │ │ (IndexedDB) │ │ (Cloud │ │ data, accepts │ │ Stores pending │ │ Workers) │ │ new input) │◄────│ mutations until │◄────│ │ │ │ │ sync succeeds) │ │ │ └─────────────────┘ └──────────────────┘ └──────────────┘ ``` ### 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. A badge on the sync indicator in the navigation bar shows the number of pending mutations in your queue. When the badge disappears, all changes have been synchronized successfully. ### 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. Clearing your browser data (cookies and site data) will delete the mutation queue. If you have unsynchronized changes, do not clear browser data for PlaneConnection until the sync indicator shows no pending mutations. ## 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. To minimize conflicts, sync frequently when connectivity is available. The system automatically syncs in the background whenever it detects a network connection, but you can also trigger a manual sync from the sync indicator menu. ## 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) This distinction matters for compliance. Under 14 CFR Part 5, the relevant timestamp for a safety report is when it was submitted, not when it reached the server. ### 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. On mobile browsers, storage quotas may be more restrictive than on desktop. If you regularly operate with large numbers of offline mutations, use a desktop browser or the dedicated mobile app for the most reliable offline experience. ## 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 How operational data is structured and stored. Data isolation architecture that offline mode respects. How to submit reports, including in offline scenarios. How offline data is protected and encrypted.