Service Workers, IndexedDB, and Why Your Reps Don't Need Bars
Your field reps in rural Queensland drive between two properties with zero bars, 40 minutes of dead zone, and a to-do list that doesn't care about signal. The second they lose connection, most SaaS field-sales tools go dark. Check-ins fail silently. Notes don't save. The rep gets back to town, refreshes the app, and now their supervisor thinks they missed three stops. Velocity X handles this differently: the moment you load today's route, the entire day gets cached locally. When signal drops, they keep working. When bars return, everything syncs.
The Architecture: Service Worker + IndexedDB + Background Sync
Velocity X registers a Service Worker on first load that intercepts every API request and caches the response. Route data, lead profiles, task lists — all cached. When the rep's device goes offline, the Service Worker serves cached data instead of failing. Check-ins and notes are queued in IndexedDB (the browser's built-in NoSQL store) with a timestamp and status flag.
The magic happens when signal returns. The Background Sync API (supported on Android and desktop PWAs) triggers a sync event that flushes the queue to your server. If a check-in was timestamped 2:47pm offline but syncs at 3:15pm when signal returns, the server records the actual event time — not the sync time. Reps see a notification badge: "Syncing 5 queued check-ins..." and within seconds, they're caught up.
Last-Write-Wins Conflict Resolution
What if a rep updates a lead note offline, and a supervisor edits the same lead in the dashboard while they're out of range? The queue payload includes a last-modified timestamp. When sync fires, the server compares: if the server version is newer, the queue item is skipped (supervisor's edit wins). If the rep's offline edit is newer, it overwrites. Simple, conflict-free, and transparent.
For truly critical scenarios (multi-user concurrent edits), Velocity X tracks sync state in the UI: "This note was updated by someone else, tap to review." The rep can merge or discard. In practice, field sales rarely collides — the supervisor doesn't touch a rep's notes while they're out on route.
The Offline Experience in Practice
A rep leaves town. Route loads. Offline cache is built. Bars drop at kilometre 12. The UI shows a greyed-out signal icon — reps know they're offline but the app keeps working. They tap a stop to check in: "Checked in offline" notification. They take photos, add notes. All queued. They complete the next four stops in zero-signal territory. When they drive back into range at 4pm, the badge pops: "Syncing..." and sixty seconds later, the CRM reflects all five stops with the correct timestamps.
Frequently Asked Questions
Does this only work for today's route?
Yes. The Service Worker caches the current day. You can't browse historical data offline — only today's active route, assigned leads, and task list.
What if the device storage is full?
IndexedDB respects device quota. If the device runs out of storage, queued items fail gracefully and notify the rep. Once they free space, the next sync attempts to flush.
Does it work on iOS?
iOS Web App mode (home-screen PWA) supports Service Workers and IndexedDB, but not Background Sync API. Reps can still work offline and sync manually — they just need to open the app again when signal returns.
How much local data gets cached?
Route data + lead profiles for a typical 20-stop day: 2–4 MB. Photos taken offline add incrementally. Most phones have hundreds of MB available for web storage.
The Bottom Line
Offline-first architecture isn't new, but it's rare in field-sales tools because it requires thoughtful sync logic and conflict resolution. Velocity X bakes it in: your reps work uninterrupted whether signal is strong or nonexistent, and the CRM stays in sync. For teams working rural territories where dropped calls are the norm, not the exception, offline mode isn't a feature — it's the difference between a tool that works and one that gets left in the truck.