BlogData conflicts
Synchronizing data: deciding when two people change the same field
Receiving both edits does not decide which the business should use. Agree field rules and preserve changes needing review.
Test worksheet: Data synchronization: rules for conflicting changes
Receiving both edits does not decide which the business should use. Agree field rules and preserve changes needing review. Record inputs, expected outcome, evidence, owner and observed result.
Give each field an appropriate rule
A new note may be added without replacing another; a negotiated price cannot always be replaced by the latest one. Classify fields that permit merging, fields with an authorized source and fields needing review. Inventory movements and adjustments need their own rules: synchronizing an absolute balance is not the same as recording every receipt and issue.
CouchDB explains that its selected winning revision can hide other revisions from ordinary views until a conflict is resolved. Visibility does not turn that revision into a business decision. Microsoft Field Service documents synchronization intervals and dependencies; moving data at a particular frequency does not itself resolve incompatible edits.
Fictional example: price and phone in version seven
A distributor has record F-090, version seven: agreed price 100 MXN and phone ending 0101. In the office, sales changes the price to 110, creating version eight. Offline, another person changes that same price to 105 and the phone to 0202 while still using version seven. These synthetic inputs test decisions; they are not Nightly commercial rules.
After reconnection, price remains in conflict: 105 does not silently replace 110. The phone can be proposed as an independent edit if the agreed rule permits it and nobody else changed that field. An owner compares prices and records the decision. Retaining the starting version explains why the second edit was not accepted in full.
| Type | Proposed treatment | Business question |
|---|---|---|
| Identified new note | Add once without replacing earlier notes | Can the note exist independently? |
| Field without concurrent editing | Apply after version and dependency checks | Did anything change its meaning? |
| Price edited in two sources | Owner review without silent selection | Which commitment is authorized? |
| Single-source field | Accept its source or retain proposal separately | Who can decide this value? |
Expose saved, sent and resolved states
Users must distinguish local entry from server acceptance. Show the conflict reason and a reference for resuming work; do not show generic success when part of the edit remains pending. If another person must decide, preserve both values and assign the case.
| Case | Expected result | Evidence |
|---|---|---|
| F-090 sends 105 from version seven | Price held for review against 110 in version eight | Both versions and conflict |
| 0202 phone without another edit | Independent application only under the agreed rule | Field and merge decision |
| Authorized price resolution | New version with decision and owner | History and final value |
| Resend the same local edit | No duplicate note or change | Change key and attempts |
| Resolve using an outdated version | Review again rather than overwriting later edits | Compared versions |
| No connection after saving | Local entry visibly pending | Local state and time |
A retry must not erase a conflict
If a response is lost after application, query the result by change identifier before creating another. If a conflict remains open, repeated sending must not turn it into acceptance. If a user's permission changed while offline, decide which entries can be accepted on return: local storage does not demonstrate current authorization.
Options depend on the product, version model and data allowed offline. Device clocks can be wrong, so do not use them as the only priority rule. Resetting an environment may remove local data depending on its design. Rehearse recovery and authorized export of pending entries before asking a user to delete or reinstall an application.
Connect the rule to work that depends on the data
A pending price may block a quote; a pending address may block dispatch. Define the consequence and the owner who can unblock it. For visit files, see offline field-service evidence; for notices, webhooks and retries; and for decisions, a change audit log.
Adapt the worksheet to data actually edited in two places. Bring versions, owners and an anonymized exception to a free consultation on process automation. We can review whether the current system supports a sufficient rule or which boundary needs testing.
Frequently asked questions
Only if the business accepts that field rule and can define latest. Local time, arrival and version are different references. Prices or commitments may require retaining both proposals and asking an owner to decide.
Sometimes, but check dependencies. Independently changing an address and delivery date can produce a combination nobody authorized. The rule must specify which fields are independent and which need joint review.
Define which authorization is checked at synchronization and how rejected entries remain available for review. Saving offline does not guarantee permission to apply later. The product's behavior needs a specific test.
No. It is a rehearsal guide with fictional inputs. Test local storage, restart, sending and resolution on actual devices and versions. Filling expected results is different from executing the test.
Sources
- Configure offline data synchronizationMicrosoft
- Replication and conflict modelApache CouchDB
Last updated: