Related
Recommended
Eli Torres (Staff)

Alright, this one's been a long time coming. Starting today, the FieldPulse mobile app goes fully offline on both iOS and Android — and I mean actually offline, not the "kinda works if you squint" version some of you may have wrestled with in the past.

What "Fully Offline" Actually Means

Your technicians can now:

  • View assigned work orders (cached locally on app launch)
  • Complete jobs, capture photos, fill checklists, and collect signatures — all without a signal
  • Queue everything for automatic sync once connectivity returns

The app handles conflict resolution if someone else edited the same work order while you were offline. Yeah, this one tripped me up too when I first looked at it — the merge logic prioritizes field-collected data over dispatch edits in most cases, unless the dispatch edit happened after your offline timestamp. Edge case worth knowing about.

Technical Bits (Because I Know Some of You Want Them)

We moved from a "fetch on demand" model to a SQLite-backed local store with background sync workers. Roughly speaking:

// Your offline queue lives here until the worker runs
POST /api/v2/workorders/{id}/offline-update
→ queued locally → sync worker → server reconciliation

The sync worker runs every 60 seconds when connected, or immediately on reconnection. Large photo batches get chunked. Checklist submissions with 50+ items have been tested up to ~15MB without issues.

One gotcha: if your org uses custom role permissions, those get cached at login. New permission changes won't reach an offline device until the next full session. Something to file under "known limitation" for now.

Getting Started

Update to mobile app version 3.4.0 or later. The offline toggle is under Settings → Sync & Storage → Enable Offline Mode. There's a brief one-time download of your active work orders and reference data.

If you've got questions about the sync behavior or want to poke at the API changes, I'm around. For general how-to stuff, this troubleshooting doc covers the basics.

Parents

  • This addresses a major operational risk for our distributed teams. Two questions:

    1. Is there a dashboard or API endpoint to monitor which technicians are currently offline vs. synced?

    2. What's the retention policy for unsynced data if a device is lost or damaged before upload?

    From a governance perspective, we need to understand our exposure window.

Comment

  • This addresses a major operational risk for our distributed teams. Two questions:

    1. Is there a dashboard or API endpoint to monitor which technicians are currently offline vs. synced?

    2. What's the retention policy for unsynced data if a device is lost or damaged before upload?

    From a governance perspective, we need to understand our exposure window.

Children
  • in reply to Keiko Tanaka

    Keiko —

    1. Yes, new endpoint at GET /api/v2/technicians/sync-status. Returns last sync timestamp, pending queue size, and connection state per device. Docs here once v2.1 ships next week.

    2. Local SQLite is encrypted at rest using the device's keychain. Data persists until explicitly cleared or the app is uninstalled. However (and this is the important part), unsynced work is device-local only — no cloud backup of the queue. If a device is destroyed before sync, that data is gone. Worth flagging in your field procedures.

    We're looking at encrypted backup to temporary cloud storage as a 2026 item, but nothing committed yet.