Several people editing the same Google Sheet: how to stop overwrites

Short answer: Google Sheets has no conflict handling. When two people write to the same cell a few seconds apart, the last write wins, the first disappears, and nobody is told. This isn't a sync failure, sync works perfectly. It's that a spreadsheet's unit of writing is the cell, and a cell holds exactly one value.

Why you're never warned

In a code tool, two concurrent edits produce a conflict a human has to resolve. In a collaborative spreadsheet that would be unbearable: you couldn't type in a file alongside someone else without constantly arbitrating. So Google chose the opposite, applying the last write, silently, so typing stays fluid.

That's the right trade-off for writing together. It's the wrong trade-off for a business record, because the cost of a mistake isn't the same: nobody dies from an overwritten paragraph, but an order flipped to "Delivered" by accident goes to invoicing.

Your colleague's coloured cursor warns you if they're already in the cell when you click. It doesn't warn you that they were there four seconds ago.

What Sheets actually protects

There are real guardrails, and you should exhaust them before considering anything else:

• Protected ranges (Data, then Protect sheets and ranges). Restrict writing on a range to specific people, or show a warning on edit. It's the only genuinely binding write mechanism in Sheets.
• Edit warnings. Weaker than protection, but enough to stop an absent-minded edit on a formula column.
• Cell edit history (right-click, then Show edit history). Tells you who wrote the current value and the one before it. Useful post-mortem, useless as prevention.
• Notification rules (Tools, then Notification rules). An email when the file changes. Noisy, but better than nothing on a critical file.
• Filter views instead of plain filters: a normal filter applies to everyone at once and makes the file move under your colleagues' hands. A filter view is private. That single detail removes a good share of accidental overwrites.

What doesn't exist: row locking, per-row write permission, conflict detection, or any way to see who changed what on a given row without walking the history by hand.

The conventions that actually hold

On a shared file meant to last, four rules do most of the work:

One column, one owner. The real problem isn't ten people writing in the file, it's two people writing in the same column. Assign columns by name and collisions almost entirely disappear.

Nobody writes in the calculation zone. Protect every formula column, no exceptions. Five minutes of setup, and it removes the single most common incident.

Entry happens through a form, not in the grid. A row created by a form is appended at the bottom: two people can't step on each other. Watch out for how fragile Google Forms columns are, though, covered here.

History is frozen. Closed rows get pasted as values into a protected archive tab. You can't overwrite what you can no longer edit.

Bonus: a "Log" tab where everyone notes what they just changed only works if the team keeps it up. In practice, it lasts three weeks. Don't build your safety on it.

The limits of conventions

Two cases come up more than the rest, and each has its template: job scheduling and inventory management.

A convention is a rule nothing enforces. It works while the team is small, attentive, and stable. It breaks at the first new hire, the first holiday cover, the first contractor who needs to enter ten rows.

The signal that you've crossed over is simple: you've started checking the file. You reopen rows to make sure nobody touched them, you ask for confirmation by message, you keep a copy just in case. That checking time is the real cost of the shared spreadsheet, and it shows up in no budget.

Overwriting is only one of the six limits of a Sheet used as a database, and it happens to be the one you notice fastest. To find out whether the others apply to you too, four questions are enough.

A database needs no convention, because the unit of writing is no longer the cell but a field on a row: two people can edit the same order at once without overwriting each other, every value keeps its author and timestamp, and a reader stays a reader.

In Rowbase your team types into a typed grid with three roles, admin, editor and viewer, with viewers free. Every row goes back into your Google Sheet automatically. You keep your calculations, you lose the overwrites.

Try Rowbase →

FAQ

How many people can edit a Google Sheet at once? Google caps editing at 100 open tabs or devices at a time. But the problem shows up long before 100: two people aiming at the same cell is enough.

Can you lock a row while you edit it? No. Sheets has no edit lock. You can protect a range permanently; you can't reserve one temporarily.

How do I find out who overwrote a value? Right-click the cell, then Show edit history. You'll see the author and the previous value. For a whole row, or a date range, you have to walk the file's version history by hand.

How do I recover overwritten data? File, Version history, See version history, then restore or copy the value out of an earlier version. Do it quickly: older versions get grouped together over time.

Are protected ranges enough to secure a shared file? They protect areas, not rows. If each person should only see or edit their own rows, Sheets has no answer for that.