Mobile apps data sync fails on poor connectivity, causing data loss

BPM OutSystems
, , , , , , , ,
1

We’re experiencing critical data sync failures in our field service mobile app when technicians work in areas with poor network connectivity. The app uses Service Studio’s offline sync capabilities, but we’re losing transaction data when the connection drops during sync operations.

The main issues we’re facing:

  • Offline queue doesn’t seem to persist failed sync attempts reliably
  • Users get generic error messages with no actionable guidance
  • Large payloads (work orders with photos) timeout before completion

Current sync implementation:


SyncEntity(
  EntityName: "WorkOrder",
  SyncUnit: "All"
);

Has anyone implemented robust offline sync queue management with proper error notifications and payload optimization? We need to ensure zero data loss for our field operations.

2

That makes sense about separating sync strategies. How do you handle payload optimization for the large attachments? Our work orders often include 5-10 photos (2-3MB each), and those are the ones consistently failing on poor connections.

3

Here’s a comprehensive solution addressing all three focus areas:

Offline Sync Queue Management: Implement a persistent local queue using Local Storage entities. Create a SyncQueue table with fields: EntityType, EntityId, Payload, AttemptCount, LastAttemptTime, Status, ErrorMessage. Process this queue on connectivity restoration with intelligent retry logic:


// Pseudocode - Queue processing:
1. Check network connectivity status
2. Fetch SyncQueue items WHERE Status = 'Pending' AND AttemptCount < 5
3. For each item: attempt sync with timeout = 30s
4. On success: mark Status = 'Completed', remove from queue
5. On failure: increment AttemptCount, update LastAttemptTime, calculate next retry delay (exponential backoff)

User Error Notifications: Replace generic errors with contextual feedback. Create a notification framework that maps technical errors to user-friendly messages:

  • Network timeout → “Slow connection detected. Will retry automatically when signal improves”
  • Server error → “Server temporarily unavailable. Your data is safely queued”
  • Validation error → “Work order missing required photos. Please add and retry”

Implement a sync status dashboard showing pending items count, last successful sync time, and per-entity status indicators.

Payload Optimization: For large attachments, implement three-tier optimization:

  1. Client-side compression: Resize images to max 1920px width, compress to 85% JPEG quality before sync. This typically reduces 3MB photos to 300-500KB.

  2. Chunked upload: Split payloads >1MB into 500KB chunks. Store chunk progress in SyncQueue:


ChunkUpload(
  FileId: workOrder.PhotoId,
  ChunkSize: 524288,
  TotalChunks: calculatedChunks,
  CurrentChunk: progressTracker
);
  1. Priority-based sync: Sync critical data (work order details, status updates) immediately with small payloads. Queue photos for background sync when connectivity is stable (signal strength >3 bars).

Additional Implementation Tips:

  • Implement connection quality detection (ping test before large syncs)
  • Add sync progress indicators with estimated time remaining
  • Store sync metrics (success rate, average time) for monitoring
  • Create admin dashboard showing fleet-wide sync health
  • Test thoroughly with network throttling tools (Chrome DevTools, Charles Proxy)

This approach has eliminated data loss in our deployments serving 500+ field technicians across rural areas. The key is treating offline capability as a first-class feature, not an afterthought. Monitor your SyncQueue table size - if it grows consistently, you have connectivity or server capacity issues to address.

4

Adding to Tom’s point about user feedback - implement a manual retry button that’s always accessible. Automatic retry is great, but field users need control when they know they have good connectivity for a moment.

5

We implemented a traffic light system for sync status that users love. Green = synced, Yellow = queued for sync, Red = failed with retry option. Each work order shows its status, and tapping red items shows the specific error (not connected, server timeout, validation error, etc.). This transparency reduced our support tickets by 60% because users understand what’s happening.

6

I’ve seen similar issues with default sync configurations. The SyncUnit: “All” approach is likely overwhelming your connection. Have you considered implementing incremental sync with smaller batches? Also, the offline queue needs explicit error handling - the default behavior doesn’t persist failed attempts across app restarts.