Can Two People Edit the Same Record Safely? A Concurrency Checklist for Self-Hosted Apps
Autosave, record history and a shared database do not by themselves tell you what happens when two people edit a record at once. Use this checklist to verify the behavior in your own workflows.
Why simultaneous edits deserve a deliberate test
A shared application may let several people open the same record, but that alone does not establish what happens when they change it at the same time. Depending on the application and workflow, a team may need to determine whether a later save replaces earlier values, whether a conflict is shown, or whether each change is retained. Do not assume a particular outcome without checking the application you use.
Autosave, a record history view and a shared database are not, by themselves, evidence that concurrent edits cannot lose or obscure changes. Treat those features as things to investigate, not guarantees. The goal is to confirm how the exact record type, fields, user roles and workflows behave.
- Start with records where an incorrect value would have a meaningful operational effect.
- Include routine edits by ordinary users, not only administrator accounts.
- Test the application version and configuration your team actually plans to use.
Separate same-field conflicts from different-field edits
There are at least two distinct cases to test. In a same-field conflict, two people change the same value—for example, both update a record’s status. In a different-field edit, they change separate values, such as one person updating a due date while another changes an owner. Do not treat success in one case as proof that the other is safe.
Collaborative document editing is another category. A shared document may have behavior designed around simultaneous text editing, while a CRM or project-management record may have different forms, save actions and history. Test the business record workflow itself rather than inferring its behavior from another feature in the product.
- Record each user’s starting value and intended change before testing.
- For same-field tests, use two clearly different replacement values.
- For different-field tests, verify both intended values after both users save.
Read the official documentation, then validate it
Look for official documentation for the specific application and version. Search its help or administrator documentation for terms such as concurrent editing, record locking, conflict detection, autosave, revision history, audit log and session timeout. Check whether the documentation describes the record types and user actions that matter to your team.
Documentation can explain intended behavior, but your configuration may include permissions, extensions or workflows that affect the result. Pair what the vendor documents with a controlled test. If the documentation is silent or ambiguous, record that uncertainty and use your test results rather than assuming a feature exists.
- Does the application prevent a second user from editing, or allow both users to proceed?
- If it detects a conflict, what does each user see and what choices are offered?
- Does autosave apply to this form and field, and when does a save occur?
- What does the history or audit feature record, and who can view it?
- Are documented behaviors qualified by version, configuration or user role?
Build a controlled two-user test
Use a test instance or a clearly designated test record so that the exercise cannot alter live business data. Choose two ordinary user accounts with the roles your team expects to use. Open the same record in separate browser sessions, note its starting values, and agree on distinct changes before either person saves.
Run the same-field and different-field scenarios separately. For each run, note the order of actions, what each user sees, any warning or lock message, the values remaining after saves, and what appears after both users refresh. Repeat the procedure if the result seems dependent on timing. Avoid using administrator-only access as a substitute for testing normal permissions.
- Use User A and User B with representative, non-administrator permissions.
- Write down the starting state and each user’s intended field changes.
- Have both users open the record before either makes a change.
- Test one scenario where both change the same field and another where they change different fields.
- Save in a controlled order, then refresh both sessions and inspect the stored record.
- Capture messages and observations without using real customer or employee data.
Vary timing, connections and abandoned sessions
A single simultaneous-save test may not cover the timing your team experiences. Test one user saving before the other, then reverse the order. Also test what happens when a user leaves an edit screen open, refreshes the browser, or returns after a pause. These are test conditions, not claims that the application will behave a particular way.
If your normal work includes unreliable or slow connections, test a suitable non-production setup under that condition if you can do so safely. Observe whether the user gets confirmation that a save completed, whether a pending edit remains visible, and what happens when the page is reopened. Do not interpret a value still displayed in an open browser as proof that it was saved.
- Test User A saving first and User B saving first.
- Refresh one browser after the other user saves; inspect the record again.
- Leave an edit session open and determine whether the user is warned about stale information.
- Test a dropped or delayed connection only in a safe environment, and note what the interface reports.
- Check whether an abandoned session can still submit an older value when resumed.
Check conflict visibility and recovery
A conflict is easier to manage when users can understand what happened and what to do next. During testing, look for an explicit warning, an indication that another person changed the record, or a clear way to review the current value before saving. If no such cue appears, document that finding; do not infer that a conflict was handled silently and safely.
Verify recovery using the options the application actually provides. If it offers a history or audit view, check whether it shows the relevant before-and-after values, the user, and the time in a way that helps your team restore or reconcile a change. If the application does not provide those details, decide what separate review or recordkeeping process is needed.
- Can each user tell that the record changed after they opened it?
- Can the user compare the current value with the value they intended to save?
- Can an authorized person identify which change was retained and when?
- Is there a documented, tested way to correct an overwritten or disputed value?
Include permissions, audit evidence and downstream effects
Repeat important tests with the roles that will use the workflow. Permissions may affect who can view a record, edit particular fields or inspect history, so verify the actual access expected for ordinary work. Keep test accounts and sample records separate from live operations.
If saving a record can trigger an integration or automated workflow, check the outcome as part of your test plan. Confirm whether the workflow uses the final record values you expect and whether repeated or corrected edits have any relevant downstream effect. The supplied evidence does not establish how any specific application or integration handles these cases, so verify them in the application and connected systems your team uses.
- Test with representative user roles and field-level permissions, where applicable.
- Check which changes are visible in any audit or history feature available to your users.
- List integrations and automations attached to the record type being tested.
- Confirm expected downstream results after both same-field and different-field edits.
Set acceptance criteria before relying on the workflow
Write down what safe behavior means for the workflow before the test. One team may require a visible conflict warning for competing edits to a critical field. Another may accept a different documented process, provided users can detect and reconcile changes. The important point is to make the requirement explicit and testable.
Keep a short results record: application and version, test record type, roles, steps, observed behavior, recovery options and unresolved questions. If the behavior does not meet the team’s criteria, consider a workflow change, additional review or a different application or deployment choice. Managed infrastructure can handle hosting tasks, but the application’s editing behavior and your decisions about data, access and governance still need to be evaluated.
- Define which fields and records require conflict detection or additional review.
- Specify what users must see when another person changes a record.
- Require a tested way to identify and correct an unintended value.
- Repeat the test after material application or configuration changes.
- Do not approve a workflow while a high-impact conflict scenario remains unexplained.
Frequently asked questions
Does autosave prevent lost changes when two people edit a record?
Not necessarily. Autosave describes saving behavior, but does not on its own establish how simultaneous edits are reconciled. Check the official documentation and test the same record with two ordinary user accounts.
Are edits to different fields automatically safe?
Do not assume so. Test separate-field edits independently from same-field conflicts, then refresh both sessions and verify the final record values.
Is record history enough to recover an overwritten value?
That depends on what the specific application records and who can access it. Verify whether the history shows the relevant values, user and time, and test the recovery process your team would use.
Should concurrency testing use administrator accounts?
Use representative ordinary user accounts for the main test. Administrator access can differ from normal permissions, so it should not stand in for testing the roles that will edit records day to day.
Does self-hosting determine how concurrent edits work?
The hosting model alone does not establish an application’s record-editing behavior. Check the application’s official documentation and test the relevant workflows in the configuration you plan to use.
Sources and further reading
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group