[Blog]()Data 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. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Synchronization needs a record identifier and the version each change was based on. When two people edit the same field, apply an agreed business rule or keep a visible conflict for review. The last arrival should not automatically decide prices, balances or delivery commitments. ## 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. [Download CSV worksheet]() In this guide - [Give each field an appropriate rule]() - [Fictional example: price and phone in version seven]() - [Expose saved, sent and resolved states]() - [A retry must not erase a conflict]() - [Connect the rule to work that depends on the data]() ## 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. ## Review two edits to the same record Bring a record with both versions and a pending or rejected edit. In a free consultation, decide which source owns each field and which conflict the business must resolve before synchronizing. - One record editable in two sources, with versions - Authority rules for prices, statuses and contact data - An anonymized pending or rejected edit [Book a free consultation]()[Ask on WhatsApp]() Related - [Process automation]() - [Custom ERP and CRM]() ## Frequently asked questions ### Can we always keep the latest change? 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. ### Can changes to different fields be merged? 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. ### What if the user changes role while offline? 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. ### Does the worksheet establish that an app works offline? 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 1. [Configure offline data synchronization]()Microsoft 2. [Replication and conflict model]()Apache CouchDB Last updated: October 8, 2026 ## Keep reading [Field serviceOct 7, 2026 ### Offline field-service evidence: from the phone to accepted work]()[Integration eventsOct 8, 2026 ### Failing webhooks: retrying without duplicate work or lost events]()[Change auditingOct 8, 2026 ### Change audit logs: who changed what and how to investigate a difference]() --- Canonical: https://nightlysoftware.com/en/blog/data-sync-conflict-rules Updated: 2026-10-08 Description: Decide which change to retain when two users edit the same data. Test versions, review and retries with a practical conflict-resolution worksheet.