{"id":21,"date":"2026-06-02T09:26:00","date_gmt":"2026-06-02T09:26:00","guid":{"rendered":"https:\/\/wisegrid.co\/blog\/collaborative-spreadsheet-edits-disappear\/"},"modified":"2026-06-10T16:23:13","modified_gmt":"2026-06-10T16:23:13","slug":"collaborative-spreadsheet-edits-disappear","status":"publish","type":"post","link":"https:\/\/wisegrid.co\/blog\/collaborative-spreadsheet-edits-disappear\/","title":{"rendered":"Why Edits Disappear in Shared Spreadsheets (and How to Stop It)"},"content":{"rendered":"<p><em>By <a href=\"\/blog\/author\/ryan-kramer\/\">Ryan Kramer<\/a>, founder of Wisegrid. Last updated June 2026.<\/em><\/p>\n<p>You typed a value into a shared spreadsheet, saw it save, moved on. An hour later it&#8217;s gone \u2014 back to the old number, or to something a teammate typed. Nobody deleted it on purpose. There&#8217;s no error, no warning, no record of what happened except a quiet wrong value sitting where your work used to be.<\/p>\n<p>This is one of the most common and most maddening failure modes of collaborative spreadsheets, and it isn&#8217;t a bug. It&#8217;s the <em>designed<\/em> behavior of how most multi-user spreadsheets resolve two people editing at once. The term for it is <strong>last-write-wins<\/strong>, and once you understand it, you can predict exactly when your edits are at risk \u2014 and pick tools and habits that protect them. When I built Wisegrid, I designed the save path so this can&#8217;t happen silently in the first place \u2014 more on exactly how below.<\/p>\n<p>I spent years inside Smartsheet before building <a href=\"\/features\">Wisegrid<\/a>, so I&#8217;ll explain the general case first (it applies to Smartsheet, Excel for the web, and Google-Sheets-style shared editing in different degrees), then show the specific design choice we made to stop silent overwrites. This is written to be useful even if you never switch tools \u2014 the diagnosis matters more than the pitch.<\/p>\n<blockquote>\n<p><strong>Key takeaways<\/strong> &#8211; **Edits disappear because of <em>last-write-wins<\/em> concurrency:<strong> when two people change the same data against the same starting point, the last save quietly overwrites the earlier one. No conflict, no warning. &#8211; <\/strong>The risk spikes with <em>stale reads<\/em>:<strong> you opened the sheet, someone else saved, and you saved over their change without ever seeing it \u2014 common in save-based tools that don&#8217;t live-sync. &#8211; <\/strong>Real-time co-editing (Google Sheets style) hides most of this<strong> by syncing keystrokes \u2014 but it has its own loss modes (offline edits, paste-over, accidental overwrites of a whole range). &#8211; <\/strong>The structural fix is <em>conflict detection<\/em>:** the tool checks whether the data changed since you loaded it, and if so, <em>saves both versions<\/em> and asks you to choose instead of silently picking a winner. &#8211; <strong>Wisegrid ships row-version conflict detection<\/strong> \u2014 a shipped feature, not a roadmap promise. It&#8217;s row-level conflict safety on a save-based model, not full real-time cursors (I&#8217;m precise about that below).<\/p>\n<\/blockquote>\n<nav class=\"wg-toc\" aria-label=\"Table of contents\"><div class=\"wg-toc-eyebrow\"><span class=\"lp-dot\" aria-hidden=\"true\"><\/span> On this page<\/div><ul>\n<li><a href=\"#what-last-write-wins-actually-means\">What &#8220;last-write-wins&#8221; actually means<\/a><\/li>\n<li><a href=\"#the-three-ways-edits-vanish-in-a-shared-spreadsheet\">The three ways edits vanish in a shared spreadsheet<\/a><\/li>\n<li><a href=\"#why-smartsheet-behaves-this-way-and-its-documented\">Why Smartsheet behaves this way (and it&#8217;s documented)<\/a><\/li>\n<li><a href=\"#where-real-time-co-editing-helps-and-where-it-doesnt\">Where real-time co-editing helps \u2014 and where it doesn&#8217;t<\/a><\/li>\n<li><a href=\"#when-last-write-wins-is-actually-fine\">When last-write-wins is actually fine<\/a><\/li>\n<li><a href=\"#how-to-stop-edits-from-disappearing-without-switching-tools\">How to stop edits from disappearing (without switching tools)<\/a><\/li>\n<li><a href=\"#the-structural-fix-conflict-detection-that-saves-both-versions\">The structural fix: conflict detection that saves both versions<\/a><\/li>\n<li><a href=\"#faq\">FAQ<\/a><\/li>\n<\/ul><\/nav>\n<h2 id=\"what-last-write-wins-actually-means\">What &#8220;last-write-wins&#8221; actually means<\/h2>\n<p>Picture the shared spreadsheet as a single authoritative copy living on a server. Everyone who opens it gets a <em>snapshot<\/em> \u2014 a read of how it looked at that moment. You edit your local view, then save, which writes your version back to the server.<\/p>\n<p>Last-write-wins is the rule the server applies when two saves collide: <strong>whoever saves last, wins.<\/strong> The server doesn&#8217;t compare your starting point to the current state. It doesn&#8217;t notice that the cell changed between when you loaded it and when you saved. It just takes the most recent write and stamps it over whatever was there.<\/p>\n<p>The quiet killer is the <em>starting point<\/em>. If you and a colleague both loaded the sheet when cell B12 said <code>40<\/code>, and they changed it to <code>55<\/code> and saved, your view still says <code>40<\/code>. You change B12 to <code>42<\/code>, save \u2014 and your save overwrites their <code>55<\/code> with <code>42<\/code>, based on a number that&#8217;s already an hour out of date. Neither of you ever saw a conflict. Your colleague&#8217;s <code>55<\/code> is simply gone.<\/p>\n<p>That&#8217;s the whole mechanism. It&#8217;s simple, it&#8217;s fast, and it loses data whenever two people&#8217;s edits overlap.<\/p>\n<h2 id=\"the-three-ways-edits-vanish-in-a-shared-spreadsheet\">The three ways edits vanish in a shared spreadsheet<\/h2>\n<p>Almost every &#8220;my edit disappeared&#8221; story is one of these:<\/p>\n<ol>\n<li><strong>Stale-overwrite (the classic).<\/strong> You loaded the sheet, someone saved a change you never pulled in, and your later save clobbered it. This is the dominant failure mode in <strong>save-based<\/strong> tools that don&#8217;t push live updates to your screen. You&#8217;re editing against a snapshot that&#8217;s already wrong.<\/li>\n<\/ol>\n<ol>\n<li><strong>Simultaneous same-cell edit.<\/strong> Two people change the <em>same cell<\/em> within the same save window. One value survives; the other is discarded by whatever resolution rule the tool uses (usually last-write-wins).<\/li>\n<\/ol>\n<ol>\n<li><strong>Range\/paste-over.<\/strong> Someone pastes a block, drags a fill, or deletes a range that happens to include cells a teammate just edited. Even in real-time co-editors, a careless paste over a populated range overwrites everything under it, and it can be hard to tell what was lost.<\/li>\n<\/ol>\n<p>Notice that #1 doesn&#8217;t require true <em>simultaneity<\/em> at all. The two saves can be an hour apart. All it takes is one person reading a stale snapshot. That&#8217;s why &#8220;but we weren&#8217;t even editing at the same time&#8221; is no defense \u2014 the overlap is in the <em>starting point<\/em>, not the clock.<\/p>\n<h2 id=\"why-smartsheet-behaves-this-way-and-its-documented\">Why Smartsheet behaves this way (and it&#8217;s documented)<\/h2>\n<p>Smartsheet is a save-based collaborative spreadsheet, and its concurrency behavior is documented in its own help center. When two people change the same cell at roughly the same time, Smartsheet&#8217;s documentation states plainly: <strong>&#8220;the cell displays the last saved change.&#8221;<\/strong> (Source: Smartsheet, <em>Work with multiple people on a sheet at the same time<\/em> \u2014 help.smartsheet.com.)<\/p>\n<p>That is last-write-wins, stated in product documentation. There is no conflict dialog, no merge prompt, and no &#8220;someone else changed this row since you loaded it&#8221; warning. The data loss is silent by design.<\/p>\n<p>Two things make this sting in real Smartsheet use, and they&#8217;re worth naming because they generalize to other save-based tools:<\/p>\n<ul>\n<li><strong>There&#8217;s no live sync of other people&#8217;s saves.<\/strong> To see a collaborator&#8217;s change, you refresh. Until you do, you&#8217;re editing against a stale snapshot \u2014 the exact precondition for a stale-overwrite.<\/li>\n<li><strong>Recovery is per-cell and manual.<\/strong> When you do notice a value got clobbered, the forensic tool is Cell History \u2014 right-click the cell, read back the prior value, re-type it. One cell at a time. There&#8217;s no &#8220;restore my whole lost edit&#8221; button.<\/li>\n<\/ul>\n<p>I&#8217;m not picking on Smartsheet here \u2014 I built a competitor, and I&#8217;m telling you their documented behavior, sourced. The point is that <strong>this is the norm<\/strong>, not an outlier. Most grid-style collaborative spreadsheets that are fundamentally &#8220;save the whole cell, last writer wins&#8221; share this shape.<\/p>\n<h2 id=\"where-real-time-co-editing-helps-and-where-it-doesnt\">Where real-time co-editing helps \u2014 and where it doesn&#8217;t<\/h2>\n<p>The other big design school is <strong>real-time co-editing<\/strong>, the Google-Docs\/Google-Sheets model: as you type, your keystrokes stream to everyone else&#8217;s screen. This genuinely <em>prevents most stale-overwrites<\/em> \u2014 there&#8217;s no stale snapshot to begin with. If your priority is &#8220;two people typing in the same sheet, seeing each other live,&#8221; that model is excellent, and Google Sheets in particular is very good at it.<\/p>\n<p>But real-time co-editing is not a magic shield against lost edits:<\/p>\n<ul>\n<li><strong>Offline \/ flaky-connection edits<\/strong> can resolve in surprising ways on reconnect \u2014 edits dropped or reordered.<\/li>\n<li><strong>Paste-over and range deletes still destroy data.<\/strong> Live sync just makes the destruction fast and synchronized.<\/li>\n<li>**Cell-level &#8220;last edit wins&#8221; still applies <em>within<\/em> a single cell.** Co-editing is best at <em>different<\/em> cells.<\/li>\n<li><strong>It&#8217;s heavier and changes the model.<\/strong> Many teams running operational trackers prefer the predictability of &#8220;I save when I&#8217;m done&#8221; over a sheet that mutates under their cursor.<\/li>\n<\/ul>\n<p>So the honest landscape is: <strong>save-based tools risk stale-overwrites; real-time tools reduce that specific risk but trade it for merge-edge-cases and a heavier model.<\/strong> Neither, by itself, <em>tells you when your save is about to overwrite someone else&#8217;s work.<\/em> That&#8217;s the gap conflict detection fills.<\/p>\n<h2 id=\"when-last-write-wins-is-actually-fine\">When last-write-wins is actually fine<\/h2>\n<p>It would be dishonest to tell you last-write-wins is always a disaster. It&#8217;s a reasonable default in plenty of cases:<\/p>\n<ul>\n<li><strong>Single-editor sheets.<\/strong> If only you ever touch it, there&#8217;s no collision to lose.<\/li>\n<li><strong>Append-only intake.<\/strong> A sheet where rows are only <em>added<\/em> (form submissions, logs) rarely has two people editing the <em>same<\/em> existing row.<\/li>\n<li><strong>Low-overlap teams.<\/strong> If collaborators own different sheets, tabs, or column blocks by convention, edits rarely collide.<\/li>\n<li><strong>Disposable \/ low-stakes data.<\/strong> If a wrong value costs nothing and is obvious on sight, the simplicity is worth it.<\/li>\n<\/ul>\n<p>The danger zone is the opposite: <strong>a shared operational tracker, many editors, the same rows touched by different people, and decisions made off the numbers.<\/strong> Project status sheets, budget trackers, inventory, anything where &#8220;whose number is right&#8221; matters. That&#8217;s where silent overwrites turn into bad decisions and &#8220;who changed this?&#8221; arguments.<\/p>\n<h2 id=\"how-to-stop-edits-from-disappearing-without-switching-tools\">How to stop edits from disappearing (without switching tools)<\/h2>\n<p>You can reduce the risk in <em>any<\/em> collaborative spreadsheet today, no migration required:<\/p>\n<ol>\n<li><strong>Refresh before you edit.<\/strong> In a save-based tool, reload the sheet right before making changes so your starting point is current. This is the single highest-leverage habit \u2014 it directly attacks the stale-snapshot precondition.<\/li>\n<li><strong>Carve up ownership.<\/strong> Assign people to rows, sections, or tabs so two editors rarely touch the same cells. Convention beats collision.<\/li>\n<li><strong>Edit narrowly, save often.<\/strong> Smaller, more frequent saves shrink the window in which someone else&#8217;s change can land between your load and your write.<\/li>\n<li><strong>Never blind-paste over a populated range.<\/strong> Paste into empty space or check what&#8217;s underneath first. Range paste-over is a top cause of &#8220;a whole block disappeared.&#8221;<\/li>\n<li><strong>Know your recovery tool.<\/strong> Learn where your tool keeps cell\/version history <em>before<\/em> you need it, so you can restore a clobbered value fast.<\/li>\n<li><strong>Use comments\/locks for hot cells.<\/strong> If a cell is being negotiated, lock it or flag it with a comment so others don&#8217;t overwrite mid-discussion.<\/li>\n<\/ol>\n<p>These habits help. But they&#8217;re discipline, and discipline fails under deadline pressure with ten editors. The durable fix is structural: a tool that simply <em>won&#8217;t<\/em> let one save silently destroy another.<\/p>\n<h2 id=\"the-structural-fix-conflict-detection-that-saves-both-versions\">The structural fix: conflict detection that saves both versions<\/h2>\n<p>Here&#8217;s the design choice that ends silent overwrites: instead of last-write-wins, the tool uses <strong>optimistic concurrency with a version check.<\/strong> Every row carries a version number. When you save, you also tell the server which version you <em>started from<\/em>. The server only applies your write if the row is still at that version. If someone changed it since you loaded it, the version won&#8217;t match \u2014 and instead of overwriting them, the server <strong>saves both versions<\/strong> and hands you a conflict to resolve.<\/p>\n<p>This is shipped in Wisegrid today. Here&#8217;s what it does, concretely:<\/p>\n<ul>\n<li><strong>Every row has a version.<\/strong> Your save includes the version you loaded plus the cells you changed.<\/li>\n<li><strong>A stale save is rejected, not applied.<\/strong> If the row moved on since you loaded it, the write doesn&#8217;t go through. Nothing of yours is lost, and nothing of theirs is clobbered.<\/li>\n<li><strong>You get a per-cell, three-way diff.<\/strong> Wisegrid compares what you <em>started from<\/em>, what&#8217;s <em>there now<\/em>, and what <em>you typed<\/em> \u2014 cell by cell. Cells only you changed auto-merge cleanly. Cells only your teammate changed are kept. Only true collisions \u2014 where you <em>and<\/em> they changed the <em>same<\/em> cell to <em>different<\/em> values \u2014 are flagged as a hard conflict for you to decide.<\/li>\n<li><strong>You see who and when.<\/strong> The conflict shows the name of whoever produced the current value and when, so it&#8217;s a &#8220;let&#8217;s reconcile&#8221; moment, not a mystery.<\/li>\n<li><strong>Both versions exist the whole time.<\/strong> Nothing is destroyed while you choose. That&#8217;s the headline: <em>no silent winner.<\/em><\/li>\n<\/ul>\n<figure><img decoding=\"async\" src=\"\/blog\/wp-content\/uploads\/2026\/06\/row-conflict-diff.png\" alt=\"Wisegrid row-version conflict modal showing a side-by-side diff of your edit versus a teammate&#x27;s saved change, with both versions preserved\" loading=\"lazy\" \/><figcaption>Wisegrid&#8217;s conflict diff saves both versions so nothing is lost.<\/figcaption><\/figure>\n<p><strong>Let me be precise about the scope, because overclaiming is how you lose trust.<\/strong> This is <em>row-level conflict safety on a save-based model<\/em> \u2014 Wisegrid keeps the simple &#8220;save when you&#8217;re done&#8221; workflow (with a non-blocking <em>&#8220;Jane saved changes \u2022 Refresh&#8221;<\/em> banner so you&#8217;re aware), and adds the version check so a stale save can never silently win. It is <strong>not<\/strong> full real-time co-editing with live cursors today \u2014 live-cursor presence is on our roadmap, not shipped, and I won&#8217;t pretend otherwise. What <em>is<\/em> shipped is the part that actually stops data loss: if your save would overwrite someone, you see a diff and choose, instead of finding out an hour later that your number is gone.<\/p>\n<p>If you&#8217;ve ever lost an edit to a silent overwrite, this is the difference you&#8217;d feel in the first hour. You can see exactly how it fits the rest of the grid on the <a href=\"\/features\">Wisegrid features page<\/a>.<\/p>\n<p>This is also the structural reason a 20-year-old save engine struggles to retrofit conflict detection: changing the write path from &#8220;last writer wins&#8221; to &#8220;reject the stale save and diff it&#8221; is a deep change to behavior that millions of existing saves depend on. Building it in from day one \u2014 as a <code>version<\/code> integer checked on every write \u2014 is cheap. Bolting it onto a legacy save path is not.<\/p>\n<blockquote>\n<p>Tired of re-typing edits a teammate clobbered? <strong><a href=\"\/features\">See how Wisegrid&#8217;s conflict detection keeps both versions \u2192<\/a><\/strong><\/p>\n<\/blockquote>\n<h2 id=\"a-note-on-capacity-because-the-two-problems-compound\">A note on capacity, because the two problems compound<\/h2>\n<p>The teams that hit silent-overwrite pain hardest are usually the ones running big, busy shared sheets \u2014 lots of rows, lots of editors. And big shared sheets run into a <em>second<\/em> wall: hard cell caps. If you&#8217;re juggling both &#8220;edits keep disappearing&#8221; and &#8220;this sheet is getting too big to manage,&#8221; they&#8217;re related symptoms of outgrowing a save-based, capacity-limited tool. We dig into the capacity side in <a href=\"\/blog\/smartsheet-cell-limit\">what Smartsheet&#8217;s 500,000-cell limit really means<\/a>, and the full head-to-head \u2014 collaboration, capacity, pricing, migration \u2014 is in our <a href=\"\/blog\/wisegrid-vs-smartsheet\">honest Wisegrid vs Smartsheet comparison<\/a>.<\/p>\n<h2 id=\"faq\">FAQ<\/h2>\n<h3 id=\"why-did-my-edits-disappear-in-a-shared-spreadsheet\">Why did my edits disappear in a shared spreadsheet?<\/h3>\n<p>Almost always because of <em>last-write-wins<\/em> concurrency combined with a stale read: you loaded the sheet, a teammate saved a change you never pulled in, and your later save overwrote theirs \u2014 based on a starting point that was already out of date. No error appears because, in most tools, this is the designed behavior, not a fault.<\/p>\n<h3 id=\"what-is-last-write-wins-in-a-spreadsheet\">What is &#8220;last write wins&#8221; in a spreadsheet?<\/h3>\n<p>It&#8217;s the rule that when two saves change the same data, the server keeps whichever was saved last and discards the earlier one \u2014 without comparing starting points or warning anyone. It&#8217;s simple and fast, but it silently loses data whenever two people&#8217;s edits overlap.<\/p>\n<h3 id=\"does-google-sheets-have-this-problem\">Does Google Sheets have this problem?<\/h3>\n<p>Less so for the <em>stale-overwrite<\/em> case, because Google Sheets uses real-time co-editing that syncs edits live, so there&#8217;s usually no stale snapshot to overwrite. But it still has loss modes: offline edits can resolve unexpectedly on reconnect, and pasting or deleting over a populated range destroys whatever was there. Real-time editing reduces one risk; it doesn&#8217;t eliminate all lost-edit scenarios.<\/p>\n<h3 id=\"how-is-conflict-detection-different-from-version-history\">How is conflict detection different from version history?<\/h3>\n<p>Version history is <em>recovery after the fact<\/em> \u2014 you go dig out a lost value and re-enter it, one cell at a time. Conflict detection is <em>prevention at save time<\/em> \u2014 the tool catches the collision <em>before<\/em> anything is overwritten, keeps both versions, and asks you to choose. History is a forensic tool; conflict detection means you rarely need it.<\/p>\n<h3 id=\"does-wisegrid-have-real-time-co-editing-with-live-cursors\">Does Wisegrid have real-time co-editing with live cursors?<\/h3>\n<p>Not today. Wisegrid is save-based with <strong>row-version conflict detection<\/strong> (shipped) plus a non-blocking &#8220;someone saved changes&#8221; banner. Live cursors \/ presence are on the roadmap, not shipped. The part that&#8217;s live is the part that stops data loss: a stale save is rejected and diffed instead of silently overwriting a teammate.<\/p>\n<h3 id=\"is-last-write-wins-ever-okay\">Is last-write-wins ever okay?<\/h3>\n<p>Yes \u2014 for single-editor sheets, append-only intake (forms, logs), teams with clean ownership of separate areas, and low-stakes data. It becomes dangerous on shared operational trackers where many people edit the same rows and decisions ride on the numbers.<\/p>\n<hr \/>\n<h3 id=\"see-conflict-safe-collaboration-in-your-own-sheets\">See conflict-safe collaboration in your own sheets<\/h3>\n<p>Wisegrid keeps the simple save model you&#8217;re used to and adds a version check so a stale save can never silently overwrite a teammate. Both versions are kept; you choose.<\/p>\n<p><strong><a href=\"\/features\">Explore Wisegrid&#8217;s features \u2192<\/a><\/strong><\/p>\n<hr \/>\n<blockquote>\n<p><strong>About the author<\/strong> <strong><a href=\"\/blog\/author\/ryan-kramer\/\">Ryan Kramer<\/a><\/strong> is the founder of Wisegrid, a higher-capacity Smartsheet alternative built around a 1,000,000-cell-per-sheet grid, conflict-safe collaboration, and a one-click Smartsheet importer. He built Wisegrid out of first-hand experience hitting the walls in Smartsheet&#8217;s grid, pricing model, and capacity limits, and writes about leaving Smartsheet without losing your data. <a href=\"\/blog\/author\/ryan-kramer\/\">More from Ryan \u2192<\/a><\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p>Edits vanish in a collaborative spreadsheet because of last-write-wins concurrency. Why a shared spreadsheet silently overwrites your work, and how to stop it.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-21","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts\/21","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/comments?post=21"}],"version-history":[{"count":3,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts\/21\/revisions"}],"predecessor-version":[{"id":42,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/posts\/21\/revisions\/42"}],"wp:attachment":[{"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/media?parent=21"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/categories?post=21"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wisegrid.co\/blog\/wp-json\/wp\/v2\/tags?post=21"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}