Find which save replaces newer work.

Two people can work at different times and still overwrite one another. First identify which source each person opened and which version their save replaced.

Protect the current work

Preserve the available file history, export or recovery copy through the system owner's approved process. Investigate with fictional records in an appropriate copy or test environment. Do not repeatedly reproduce the incident against live customer, financial or staff records.

Write a short incident timeline: record reference, source file or application, relevant time and timezone, action and expected result. Keep sensitive values out of ordinary support notes. Establish whether staff used one online workbook, emailed copies, local files or an import from another tool. An old file imported later can replace new work without simultaneous editing.

Run a two-person example

1. Both test users open fictional request A at version 3. Record the visible starting values.
2. User one changes the status from draft to reviewed and saves. Check the actual stored result, not only the screen message.
3. User two, still viewing version 3, adds a note and saves. Inspect both the note and the reviewed status.
4. Reload as each user and compare the current record with the history. Note whether the second save silently restored the old status, preserved both changes or was refused.

Repeat only the controlled variants needed to explain the issue. Include a changed value in the same field and, separately, independent fields. Those cases can require different decisions.

Agree what a conflict means

A warning and refresh may suit a consequential approval. An explicit merge can suit independent notes if ownership and history remain clear. Some tasks require the second user to review the newer record before submitting again. The business and developer must choose the intended behavior; a database or autosave label does not choose it for them.

Check that a rejected save leaves the user's unsaved text available to review. A successful save should identify the current stored result. A timeout creates uncertainty: inspect the record before retrying an action that might already have happened.

Follow the next writer

If the test looks correct but production history still changes, inspect scheduled imports, spreadsheet synchronization and background jobs. Name which source owns each field and how an older source value is detected. Preserve the source reference and a useful change history where required by the task.

A useful finding identifies the first incorrect transition and the person responsible for the next check. It does not jump from “someone lost a note” to “replace the whole system.” Bring that finding to a spreadsheet workflow review, and include the conflict example in the release checklist.