When Conflicts Occur
A data conflict occurs when the same record is modified from different sources before the changes have been synchronized. Typical scenarios:
Two Devices Offline
Two team members work offline on different devices and modify the same record. For example:
- An operator at the entrance checks in a participant and adds the comment "VIP"
- A manager on another device checks in the same participant and adds the comment "Extra seat"
- When connectivity is restored, both changes are sent to the server
Offline + Online
One team member works offline, another works online:
- A manager at their computer (online) changes a registration status
- An operator at the venue (offline) changes the same status
- During synchronization, the offline change conflicts with the already-applied online change
When Conflicts Are Unlikely
In practice, conflicts occur rarely because:
- Different team members usually work with different participants
- Check-in is a unidirectional operation (marking arrival); a check-in conflict is only possible with a double scan
- Payment operations are protected by an idempotency key
Strategy: Last-Writer-Wins (Free, Pro)
On the Free and Pro plans, the automatic last-writer-wins strategy is used:
How It Works
- During synchronization, the server compares the
clientTstimestamps of the conflicting changes. - The change with the later timestamp is automatically saved.
- The change with the earlier timestamp is overwritten.
- Both changes are recorded in the audit log (even the overwritten one).
Example
| Time | Action | Result |
|---|---|---|
| 10:05 | Operator A (offline): check-in + comment "VIP" | Saved locally |
| 10:07 | Operator B (offline): check-in + comment "Standard" | Saved locally |
| 10:15 | Operator A goes online | Change sent |
| 10:16 | Operator B goes online | Conflict. B wins (10:07 > 10:05). Comment = "Standard" |
Advantages and Limitations
Advantages:
- Fully automatic -- requires no user intervention
- Does not interrupt the workflow
- Suitable for most scenarios (check-in, simple statuses)
Limitations:
- The earlier change is lost without notification
- No ability to merge two changes
- For critically important data, this may lead to information loss
Strategy: Optimistic Locking + Merge UI (Business, Enterprise)
On the Business and Enterprise plans, an interactive conflict resolution strategy with a visual interface is available.
How It Works
- During synchronization, the server detects a conflict (the record was modified after the last state known to the client).
- Instead of automatically overwriting, the server returns both versions.
- The user is shown the merge UI -- a version comparison interface.
- The user chooses which version to keep or merges the changes manually.
Merge UI
The conflict resolution interface shows:
-
Left column: your version (local change)
- Change author
- Change time
- Modified fields with their values
-
Right column: server version (someone else's change)
- Change author
- Change time
- Modified fields with their values
-
Actions:
- "Keep my version" -- your change overwrites the server version
- "Accept server version" -- the server version is kept, your change is discarded
- "Merge" -- you manually select the value for each field
Example
| Field | Your Version | Server Version |
|---|---|---|
| Check-in | Yes | Yes |
| Comment | VIP, seat A-12 | Standard |
| Status | Confirmed | Confirmed |
You can accept the check-in from both versions (they match), take your comment, and use the server's status.
Optimistic Locking
Under the hood, optimistic locking is used:
- Each record has a version (version counter)
- When sending a change, the client specifies which version it was based on
- If the version on the server has changed (someone else updated the record), the server returns a conflict
- The client shows the merge UI
Conflict Notifications
When a conflict is detected:
Free / Pro: a toast notification "Data conflict resolved automatically" (informational, no action needed).
Business / Enterprise: a toast notification "Conflict detected. Your input is needed" with a button to open the merge UI. The conflict blocks synchronization of remaining changes until it is resolved.
Recommendations
- Assign areas of responsibility. Assign team members to different groups of participants or check-in zones to minimize conflicts.
- Sync more often. Short periods of offline work reduce the likelihood of conflicts.
- Use the merge UI for critical data. If your team actively works with the same records, consider upgrading to Business for access to interactive conflict resolution.