You are editing a Notion database with a teammate, and both of you change the same property field, such as a Select option or a text cell, at nearly the same moment. The result is a sync conflict: one edit overwrites the other, or the property shows a stale value that does not match either user’s input. This problem occurs because Notion uses a last-writer-wins conflict resolution model for property-level edits. This article explains the technical reason behind the conflict and provides practical steps to reduce or eliminate data loss when multiple people modify the same property simultaneously.
Key Takeaways: Fixing Notion Sync Conflicts on the Same Property
- Last-writer-wins model: Notion preserves only the most recent save to a property cell; earlier concurrent edits are silently discarded.
- Page-level locking (workaround): Use a status property with a “Locked” option to prevent other users from editing a row while you make changes.
- Database template with comments: Create a template that includes a comment block so teammates can claim a property before editing, reducing overlap.
Why Notion Overwrites Concurrent Edits to the Same Property
Notion’s sync engine is designed for real-time collaboration, but it does not use Operational Transformation or CRDT algorithms that merge concurrent edits at the character or field level. Instead, when two users edit the same property cell, the server accepts the last write it receives and discards the earlier one. This is called a last-writer-wins strategy.
The conflict arises because Notion treats each property cell as a single atomic unit. If User A changes a text property from “Pending” to “Approved” and User B changes the same cell to “Rejected” within a few seconds, the server saves whichever update arrives last. The other user sees their change disappear without any warning or merge dialog.
This behavior is intentional for performance and simplicity. Full conflict resolution would require version histories for every cell and a UI to choose between versions, which Notion does not currently offer. Understanding this limitation helps you adopt workflows that avoid simultaneous writes to the same property.
Steps to Prevent Concurrent Edit Conflicts on a Shared Property
- Identify the conflict-prone property
Open the database and locate the property that multiple team members edit at the same time. Common examples are Status, Assignee, or a custom text field for notes. Note the property name and type. - Add a “Locked” status option
If the property is a Select or Status type, add a new option called “Locked” or “In Progress — Do Not Edit”. This option signals to other users that someone is actively editing the row. To add it, click the property header, select Edit property, and type the new option name in the Options list. - Train the team to set the status before editing
Before making changes to a property, each team member must set the Locked status on the row. This is a manual step but it establishes a visual guard. Other users see the Locked tag and know to avoid editing that row until the status is cleared. - Use a comment to announce edits
For text or number properties that cannot be locked via status, add a comment to the row by clicking the comment icon in the top-right corner of the page. Write a brief note such as “Editing priority field — please wait”. Comments are visible to all collaborators and create a communication channel without leaving Notion. - Implement a database template with a pre-filled claim field
Create a new database template that includes a text property called “Claimed by”. Set the default value to the current user’s name using the{{user.name}}variable. When a team member creates a new row from this template, the Claimed by field automatically shows who owns the row. Others see the claim and avoid editing that row’s properties. - Use a separate database for high-conflict properties
If a property is constantly overwritten, move it to a separate linked database. Create a new database with only that property and a relation to the original database. Assign one person to edit the new database at a time. This reduces the chance of two people editing the same cell because the property is isolated in its own database.
If Notion Still Shows Stale Values After Following the Steps
Refreshing the page does not show the latest edit
If you see an outdated value even after a manual refresh, the conflict already occurred and the server saved the wrong version. Check the page history by clicking the clock icon in the top-right corner of the page. Page history shows previous versions of the entire page, including property changes. You can restore a version that contains the correct value. Note that page history is available on Notion Plus plans and above.
A property shows a value that neither user entered
This can happen if a third automation or integration, such as Zapier or Make, wrote to the same property at the exact same time. Review your connected apps in Settings & Members > Connections. Disconnect any integration that writes to the same database property without a queue or delay. For critical automations, add a one-minute delay between the trigger and the write action to reduce overlap with manual edits.
The Locked status is ignored by some team members
If users ignore the Locked status, enforce the workflow with a database view that filters out Locked rows. Create a view called “Editable” with a filter: Status does not contain “Locked”. Set this view as the default for all team members. Users see only rows that are available for editing, reducing the chance of concurrent edits.
Notion Sync Conflict Prevention Methods Compared
| Method | Effectiveness | Complexity |
|---|---|---|
| Locked status option | High when team follows the rule | Low — one property change |
| Comment-based announcements | Medium — depends on visibility | Low — no setup needed |
| Template with Claimed by field | High for new rows | Medium — template creation |
| Separate database for conflict property | Very high — isolates the edit | High — database restructuring |
Choose the method that matches your team size and editing frequency. For a small team of two to five people, the Locked status option combined with a comment is usually sufficient. For larger teams, the template approach with a Claimed by field provides a more automated guard.
Now you understand why Notion discards concurrent edits to the same property and how to prevent the conflict using status locking, comments, and database templates. Try adding a Locked status to your most-edited Select property today. For deeper control, consider moving high-conflict properties into a separate database linked by a relation — this eliminates the chance of two people editing the same cell at the same time.