Mobile offline task sync fails after network switch, causing data loss

BPM Appian
, , , , , , , ,
1

We’re experiencing critical data loss with Appian Mobile (22.4) when field agents switch between WiFi and cellular networks. Forms completed offline aren’t syncing properly after network changes.

The issue occurs when:

  1. Agent completes inspection form while offline
  2. Device switches from WiFi to cellular (or vice versa)
  3. App shows “syncing” but form data never reaches server
  4. Agent moves to next task, previous form data lost

Our mobile app config:


offlineEnabled: true
syncOnConnect: true
maxOfflineStorage: 50MB

We’ve checked background data permissions - they’re enabled for iOS and Android. The sync works fine if network doesn’t change, but any network transition causes failures. We’re seeing 15-20% data loss in field operations.

Has anyone dealt with offline form persistence and network change handling? What’s the proper background sync configuration to prevent this?

2

Good progress! For monitoring, implement the Appian Mobile SDK’s sync status callbacks. You can track pending, in-progress, and completed syncs programmatically.

However, the remaining failures suggest you need to address all four focus areas systematically. Let me provide a comprehensive solution that addresses offline form data persistence, background sync configuration, network change handling, and mobile OS permissions together.

3

Here’s the complete solution addressing all aspects of your offline sync problem:

1. Offline Form Data Persistence: Implement persistent storage with sync queue management. Update your mobile config:


offlineEnabled: true
persistentSyncEnabled: true
syncQueueMaxSize: 100
retryFailedSync: true

The persistentSyncEnabled flag ensures forms are stored in device’s persistent storage (not just memory) and survive app restarts and network changes.

2. Background Sync Configuration: Configure aggressive sync retry logic:


syncOnConnect: true
syncOnResume: true
syncRetryInterval: 300
maxSyncRetries: 5

This creates multiple sync opportunities: on network connect, app resume, and scheduled intervals. The retry mechanism handles transient network failures.

3. Network Change Handling: The critical piece is handling network transitions gracefully. Appian Mobile 22.4 has a known issue where rapid network switches can interrupt sync. Implement these workarounds:

  • Set syncDebounceDelay: 5000 (5 seconds) to prevent sync attempts during rapid network fluctuations
  • Enable networkChangeMonitoring: true which detects network switches and reschedules interrupted syncs
  • Use syncOnlyOnWiFi: false to allow cellular sync as fallback

4. Mobile OS Background Data Permissions:

iOS (Info.plist):

<key>UIBackgroundModes</key>
<array>
    <string>processing</string>
    <string>fetch</string>
    <string>remote-notification</string>
</array>

Also request “Background App Refresh” permission programmatically on first launch.

Android (AndroidManifest.xml): Add these permissions:

<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE"/>

Additional Recommendations:

  1. Increase offline storage: Change maxOfflineStorage: 200MB to accommodate form data during extended offline periods

  2. Implement sync status UI: Show users pending sync count and allow manual sync trigger. This prevents users from assuming data is saved when it’s only queued

  3. Add conflict resolution: Configure conflictResolution: 'clientWins' or 'serverWins' based on your business logic

  4. Monitor sync health: Enable mobile analytics to track sync success rates:


mobileAnalytics: true
trackSyncEvents: true
  1. Test network transitions: Specifically test WiFi→Cellular, Cellular→WiFi, and Airplane mode scenarios during form submission

Upgrade Consideration: Appian 23.2+ has significantly improved offline sync reliability with better network change handling. If possible, consider upgrading as it includes:

  • Automatic sync queue recovery after network transitions
  • Better iOS/Android background task management
  • Enhanced sync conflict detection

After implementing these changes, your data loss should drop to near zero. The key is the combination of persistent storage, retry logic, network monitoring, and proper OS permissions working together. Monitor your sync success rates through mobile analytics for 2-3 weeks to verify improvement.

4

The network switching problem has two components. First, mobile OS permissions - you need both background processing AND network access permissions explicitly granted. Second, your sync strategy needs to be resilient.

For offline persistence, implement a queue-based approach where forms are stored locally with a sync status flag. Don’t rely on automatic sync triggers alone. Add manual retry logic that survives network changes. The syncOnConnect flag is insufficient because it doesn’t handle interrupted syncs.

Also check your maxOfflineStorage - 50MB might be too restrictive if you have media attachments in forms.

5

I’ve seen similar behavior in 22.4. The issue is likely related to how mobile OS handles background sync during network transitions. When the network interface changes, the OS can terminate background processes mid-sync.

First check: Are you handling the network state change events properly in your mobile configuration? The app needs explicit permission to continue data transfers during network switches. For iOS, you need the background modes capability enabled specifically for processing not just fetch.