Our sales team uses Zendesk Sell’s mobile app extensively in areas with poor connectivity. We’re building custom offline capabilities where reps can update deal details, add notes, and log activities while disconnected. The challenge is handling sync conflicts when the same deal is modified offline by the mobile user and online by another team member before sync occurs. Zendesk’s API documentation mentions conflict detection but doesn’t detail resolution strategies. How do you handle field-level conflicts versus record-level conflicts? Do you implement last-write-wins, manual conflict resolution UI, or field-level merge logic? We’re particularly concerned about losing important updates when conflicts arise. What patterns have worked for others building offline-capable mobile integrations with Zendesk Sell?
Building on this discussion, here’s a comprehensive approach to handling offline-online sync conflicts in mobile CRM integrations with Zendesk Sell.
Offline API Capabilities Architecture:
Zendesk Sell’s mobile API supports offline operation through local data caching and queued sync operations. The pattern involves:
- Data Download: Fetch relevant records (deals, contacts, activities) when online and store locally with full metadata including ‘updated_at’ timestamps
- Offline Modifications: Track all local changes with field-level granularity in a change log
- Sync Queue: When connectivity returns, process queued changes with conflict detection before API submission
- Conflict Resolution: Apply appropriate strategy based on conflict type and business rules
Sync Conflict Scenarios:
Common conflict patterns in mobile sales scenarios:
- Concurrent Field Updates: Same field modified offline and online (e.g., both users update deal value)
- Record State Conflicts: Record deleted online but modified offline
- Relationship Conflicts: Associated records changed (contact removed from deal that was updated offline)
- Validation Conflicts: Offline changes violate constraints added online (new required fields, changed picklist values)
Conflict Resolution Strategies:
1. Field-Level Timestamp Tracking Implement granular change tracking:
- Store field-level ‘last_modified’ timestamps in local database
- During sync, compare field timestamps between local and server versions
- Only submit fields that were modified offline and haven’t been updated online since last sync
- This allows partial record updates and preserves non-conflicting changes
2. Tiered Resolution Based on Field Criticality
Low-Risk Fields (Auto-Merge):
- Description, notes, tags: Append/merge content
- Activities, tasks: Always create (additive operations)
- Custom text fields: Use most recent timestamp
Medium-Risk Fields (Notify + Auto-Resolve):
- Contact information: Last-write-wins with notification
- Expected close date: Use most recent with alert
- Deal source, campaign: Preserve online value, log conflict
High-Risk Fields (Manual Resolution Required):
- Deal value/amount: Show conflict UI, user chooses
- Deal stage: Require manual selection
- Deal owner: Prevent automatic change, show both options
- Win/loss status: Always require user decision
3. Optimistic Locking Implementation
Since Zendesk Sell API lacks native version control:
// Pseudocode - Conflict detection flow:
1. Store original 'updated_at' when fetching record offline
2. Before sync, fetch current server version of record
3. Compare stored timestamp with current server timestamp
4. If timestamps differ, detect which fields changed:
- Parse both versions and diff field values
- Identify conflicting fields (changed both places)
5. Apply resolution strategy based on field type
6. Submit update with conflict-resolved values
4. Conflict Resolution UI Pattern
For manual resolution scenarios:
- Display side-by-side comparison: “Your offline value” vs “Current server value”
- Show who made the server change and when
- Provide “Use Mine”, “Use Theirs”, “Merge” options
- Allow field-by-field selection for complex conflicts
- Log all conflict resolutions for audit trail
Implementation Best Practices:
Change Queue Management:
- Sequence operations: Creates before updates, deletes last
- Group related changes: Contact + Deal + Activity in transaction
- Retry failed operations with exponential backoff
- Preserve change order to maintain business logic
Sync Performance:
- Batch API calls where possible (Zendesk supports bulk endpoints)
- Fetch only changed records using ‘updated_since’ filters
- Implement delta sync rather than full refresh
- Compress large note/description fields during transmission
Data Integrity:
- Validate all offline changes before sync submission
- Check referential integrity (parent records exist)
- Verify picklist values haven’t changed
- Handle API validation errors gracefully with user feedback
Edge Cases to Handle:
- Network drops during sync: Mark partial success, resume from checkpoint
- Multiple conflict cycles: User goes offline again before resolving previous conflicts
- Cascading deletes: Parent record deleted online, child records modified offline
- Permission changes: User loses access to records they modified offline
Our production implementation uses this tiered approach with field-level tracking. We see conflicts in about 3-5% of sync operations, with 80% auto-resolved using the low-risk merge rules. The remaining 20% requiring manual resolution are primarily deal stage and value changes, which is appropriate given their business impact. The key insight is that granular field-level tracking dramatically reduces data loss compared to record-level last-write-wins strategies.
Zendesk Sell doesn’t have built-in optimistic locking with version numbers like some systems. You need to implement it yourself by storing the ‘updated_at’ timestamp when you fetch a record, then checking if it’s changed before applying your update. If the timestamp differs, you have a conflict. Some developers use ETags in custom headers for this purpose.
How do you handle the API’s optimistic locking mechanism? Does Zendesk Sell’s API support conditional updates based on version numbers or timestamps to prevent overwriting newer data?
Don’t forget about related entity conflicts. If a mobile user adds a contact to a deal offline, but that deal is deleted online before sync, you need cascading conflict resolution. We maintain a dependency graph of offline changes and resolve conflicts in order: contacts first, then deals, then activities. This prevents orphaned records and maintains referential integrity.
Consider the business impact of different conflict types. Losing a note update is less critical than overwriting a deal stage change. We implemented a tiered strategy: automatic merge for low-risk fields (descriptions, notes), user notification for medium-risk (contact info, dates), and mandatory manual resolution for high-risk (deal value, stage, owner). This balances automation with data integrity.
We use a timestamp-based last-write-wins approach for most fields, but with exceptions for critical data. Deal value, stage, and close date use manual conflict resolution where we show both versions to the user and let them choose. For notes and activities, we append rather than overwrite since those are additive by nature. The key is having good conflict detection using the ‘updated_at’ timestamp from the API.
Field-level conflict resolution is complex but worth implementing. We track field-level timestamps in our local database so we know exactly which fields changed offline versus online. During sync, we only send modified fields and can detect conflicts at the field level rather than rejecting the entire record. This minimizes data loss - if the mobile user updated deal notes but someone else changed the value online, both updates can be preserved.