Was this helpful?
Was this helpful?
In this Article
  • Created

Article Data Loss After Offline Session — Cause and Resolution

Summary

Critical data loss occurs when offline sessions exceed 72 hours without successful sync.

Symptoms

Technicians working in areas with limited connectivity may notice that work orders completed offline appear to save successfully, but upon reconnecting, some or all of that data is missing. In my experience, this typically manifests in one of three ways:

  • Work orders show as "completed" but checklist responses, photos, or notes are empty
  • Jobs completed offline revert to "in progress" status after sync
  • Entire work orders created offline disappear entirely from the technician's device

Affected Versions and Platforms

FieldPulse Mobile App 3.0.8 through 3.1.2 on both iOS and Android. The issue is more prevalent on Android devices with aggressive battery optimization settings, but I have seen it occur on iOS as well.

Cause

What I typically recommend is understanding the root cause before attempting any recovery. The FieldPulse mobile app uses a local SQLite database for offline storage, with a background sync queue that processes changes when connectivity returns. In versions 3.0.8–3.1.2, a race condition was introduced between the sync scheduler and the local data retention policy.

Specifically: the app was configured to retain unsynced data for 72 hours as a safeguard against device storage bloat. However, due to a timer initialization bug, this cleanup routine could trigger before the sync process completed, particularly when the app was backgrounded for extended periods or when the device entered low-power modes. The sync queue would see "no pending changes" because the underlying records had been purged, and would mark the sync as successful—when in fact the data was gone.

In my experience, this is more likely to occur when:

  • A technician works offline for more than 48 hours
  • The device is restarted while offline
  • Multiple apps are competing for background processing time

Resolution

The definitive fix is to update to FieldPulse Mobile App 3.1.3 or later, where the data retention timer is properly gated behind sync completion status. To update:

  1. Open the App Store (iOS) or Google Play Store (Android)
  2. Search for "FieldPulse"
  3. Tap Update if available, or Open if already on 3.1.3+

For teams still on affected versions, what I typically recommend is configuring a forced sync reminder at the 24-hour mark, which can be enabled in Settings → Offline Mode → Sync Reminders.

Data Recovery

If data loss has already occurred, recovery options are unfortunately limited. The data is removed from the local database without backup. However, in some cases where the app was force-closed rather than backgrounded, the SQLite WAL (Write-Ahead Log) may contain recoverable fragments. Contact FieldPulse Support with the device ID and approximate time of data entry—our team can attempt WAL recovery if the device has not been heavily used since the incident.

Prevention

Beyond updating, I would also recommend:

  1. Adopting a sync-before-end-of-day policy for field teams
  2. Disabling aggressive battery optimization for the FieldPulse app (Android: Settings → Apps → FieldPulse → Battery → Unrestricted)
  3. Using Wi-Fi sync when returning to the office, as cellular sync can be interrupted more easily

For more on configuring offline mode best practices, see FieldPulse Now Supports Offline Mode on iOS and Android.

Last updated: October 2, 2025. If you are still experiencing this issue after updating to 3.1.3, please reply below with your device model and OS version so we can investigate further.

  • in reply to Josh Mercer
    • Confirmed the logout issue—had a tech lose 6 hours of data last month because they toggled accounts troubleshooting a login problem
    • We now have a strict "one device, one account" policy
    • Also: update your devices. 3.1.3 has been stable for us across 40+ field units

    Thanks Daniel for the detailed writeup—much clearer than the release notes.

  • Pro tip: if you're stuck on an older version and can't update immediately, have your techs open the app and manually trigger a sync every evening before they head home—even if they're still in a dead zone. The sync will fail (obviously), but it resets that 72-hour timer. Keeps the data alive until they hit better signal.

    We've been doing this with our rural routes for two years. Not elegant, but it works.

    Also worth noting: the offline data is more fragile if your techs are switching between multiple FieldPulse accounts on the same device. The local DB gets wiped on logout, which is easy to accidentally trigger when frustrated with a failed sync.

  • Rachel, excellent detail—thank you for the reproduction steps. To answer your question: the 3.1.3 fix does address the WAL timing indirectly. Previously, the sync completion signal was not properly flushing the WAL to the main database before the retention check ran. In 3.1.3, we now ensure that SYNC_COMPLETED status is only set after WAL commit, which prevents the race condition you observed.

    That said, what I typically recommend for Galaxy Tab A7 devices specifically is also checking Samsung's "Auto-optimize" feature (separate from Android's battery optimization), which can force-stop background apps after 3 days regardless of our internal timers. You can find this under Device care → Auto-optimization.

    Would you be able to test 3.1.3 on one of your affected devices to confirm the fix holds under your specific conditions?

  • I have confirmed that this issue is reproducible on Samsung Galaxy Tab A7 devices running Android 12 when battery optimization is set to "Optimize." I can reproduce this consistently when the device remains offline for 50+ hours.

    Specific conditions:

    • FieldPulse app version 3.1.1 (build 31204)
    • Device offline from 2025-09-28 08:00 UTC to 2025-09-30 14:00 UTC (54 hours)
    • 3 work orders created offline, 2 with complete checklist data
    • Upon sync, 1 work order retained only header data; 2 lost all checklist responses

    The SQLite database file size decreased from 14.2MB to 8.7MB immediately upon reconnection, which I believe corresponds to the WAL cleanup triggering prematurely.

    Can you confirm whether the 3.1.3 fix addresses the WAL timing specifically, or only the 72-hour retention timer?