Mobile app data sync fails after offline entry, returns 409 conflict

BPM Appian
, , , , , , , ,
1

We’re experiencing 409 Conflict errors when our mobile app users submit form data after working offline. The scenario is straightforward: field technicians capture inspection data in offline mode, then sync when they regain connectivity. However, about 30% of these syncs fail with HTTP 409 responses.

The error occurs during the POST request to our Appian integration:


POST /suite/rest/a/pm/v1/inspections
Response: 409 Conflict
{"error": "Resource modified", "code": "CONFLICT"}

We’re using Appian Mobile 22.4 with offline forms enabled. The conflict detection seems overly aggressive - even when no other user has touched the record. We’ve implemented basic ETag handling in our mobile client, but I’m concerned about data loss and user frustration when syncs fail. How do others handle offline data capture with proper conflict resolution and integration with master data systems?

2

Let me provide a comprehensive solution addressing all aspects of your offline sync challenges.

Offline Data Capture Architecture: Implement a robust versioning system in your CDT structure. Add these fields to your inspection data type:


version: Number (Integer)
lastModified: DateTime
modifiedBy: Text

When the mobile form loads, capture these values and store them in hidden fields within your offline-enabled form.

Conflict Detection Strategy: Your integration object should implement proper ETag handling. Configure the web API to:

  1. Generate ETags based on version + lastModified timestamp
  2. Validate incoming If-Match headers against current record state
  3. Return 409 only for genuine conflicts (different modifiedBy or version mismatch)

The key is distinguishing between stale client data and actual concurrent modifications. Implement this logic in your save process model:


a!localVariables(
  local!currentRecord: rule!GetInspectionById(ri!id),
  local!hasConflict: and(
    local!currentRecord.version <> ri!clientVersion,
    local!currentRecord.modifiedBy <> ri!currentUser
  )
)

User Feedback on Sync: Implement a three-tier feedback mechanism:

  1. Immediate Success: Show green checkmark for successful syncs
  2. Soft Conflicts: For same-user modifications (user edited on web while offline), auto-merge with notification
  3. Hard Conflicts: For different-user modifications, present conflict resolution UI

Create a conflict resolution interface in your mobile app that displays:

  • Server version (with timestamp and modifier)
  • Local version (with offline capture time)
  • Field-by-field comparison highlighting differences
  • Merge options: Accept Server / Keep Local / Manual Merge

Integration with Master Data: The 409 errors often stem from referential integrity issues with master data. Implement these safeguards:

  1. Cache master data locally when going offline (lookup lists, reference data)
  2. Validate foreign key references before sync attempt
  3. Implement a pre-sync validation service that checks:
    • Referenced records still exist
    • User still has permissions
    • No schema changes have occurred

ETag/Versioning Implementation: Modify your REST endpoint configuration:


Request Headers:
If-Match: "{version}-{timestamp}"
Content-Type: application/json

Response Headers (on success):
ETag: "{newVersion}-{newTimestamp}"
Last-Modified: {serverTime}

Reducing False Positives: Implement these specific fixes:

  1. Timezone Standardization: Convert all timestamps to UTC at the data layer
  2. Grace Period Logic: Allow syncs within 300 seconds if same user
  3. Optimistic Locking: Use version numbers instead of timestamps for conflict detection
  4. Idempotency Keys: Generate unique sync IDs to prevent duplicate submissions

Testing Recommendations: Create test scenarios covering:

  • Same user, multiple devices, offline edits
  • Different users, concurrent modifications
  • Network interruption during sync
  • Timezone edge cases (DST transitions)
  • Master data changes while offline

Implement these changes incrementally, starting with version field addition and ETag validation. This should reduce your conflict rate from 30% to under 5%, with remaining conflicts being genuine concurrent modifications requiring user resolution. The key is making conflict detection intelligent rather than overly cautious, while providing clear user feedback when intervention is needed.

3

Good point Mike. We’re capturing a timestamp when the form loads, but I think the issue is that we’re not sending it back properly in the sync request. The ETag header might not be formatted correctly for Appian’s expectations. Do you have an example of the proper request structure?

4

I’ve seen this exact issue before. The 409 typically happens when your offline record’s timestamp doesn’t match the server’s current state. Are you capturing the record version or timestamp when the mobile user first loads the form offline? Without proper versioning, Appian assumes a conflict exists.

5

We had similar problems and found that 60% of our conflicts were actually false positives caused by timezone mismatches between mobile devices and the server. Make sure you’re standardizing all timestamps to UTC before comparison. Also consider implementing a grace period - if the record hasn’t been modified by another user within the last 5 minutes, allow the sync to proceed even with minor timestamp discrepancies.