Our mobile sales team is experiencing critical data sync issues when working in areas with weak network connectivity. When reps reconnect, we’re seeing duplicate contact records and inconsistent opportunity data being created in Adobe Experience Cloud.
The offline sync queue doesn’t seem to handle deduplication properly. Here’s what we’re seeing in the sync logs:
SyncQueue: Processing 47 pending records
Contact C-10234: Created (duplicate of existing)
Opportunity O-5678: Updated with stale data
Our unique identifier enforcement appears broken - the system should be matching on email + phone combination but isn’t. This is causing major data integrity problems for our sales pipeline reporting. We’ve configured the mobile-sales module for offline operation, but the deduplication logic seems to fail when processing queued records in batch.
Has anyone solved sync queue design issues for mobile deployments? We need a reliable way to handle offline operations without creating duplicates when connectivity returns.
Check your identity namespace configuration in the mobile-sales module. AEC 2021 has limitations with composite key matching during batch operations. The system might be falling back to single-field matching (just email OR phone) instead of the AND logic you expect. Also verify that your offline queue is preserving the full identity context - I’ve seen cases where network interruptions cause partial record transmission that breaks matching logic.
I’ve dealt with similar offline sync challenges. The core issue is that AEC’s default sync queue processes records sequentially without checking for duplicates within the same batch. When multiple updates to the same record queue up offline, each gets treated as independent.
Your unique identifier strategy needs revision - email+phone isn’t reliable for mobile scenarios where one field might be updated offline. Consider implementing a client-side UUID that persists across sync attempts.
We had this exact problem last year. The issue isn’t just technical - it’s also about data model design for offline-first scenarios. Your contact schema needs a device-specific last-modified timestamp alongside the server timestamp. This enables three-way merge conflict resolution: server state, device state, and common ancestor. Without this, you can’t reliably determine which offline change should win when sync occurs. Also ensure your unique identifiers are being normalized before comparison (lowercase email, formatted phone).
Your sync logs show the classic symptom of missing idempotency keys. When the mobile app reconnects and retries failed operations, AEC treats each retry as a new request. Implement a client-generated transaction ID that persists with each queued operation. The server-side API should check for duplicate transaction IDs before processing creates or updates. This is especially critical for weak network scenarios where connection drops mid-transaction can cause retry storms.