Concurrent Editing Safeguards: Working the Same Model Without Overwriting Each Other

Two people open the same headcount plan. One adjusts a hiring date, the other tweaks a salary band on the same row, and both hit save within a few seconds of each other. Without a safeguard, whichever save lands second simply wins, and the first edit disappears with no error, no warning, nothing in the interface to say it ever happened. That’s the failure mode Rexfin’s concurrent editing protection is built to close.

The problem with a plain save

A save operation that just writes over whatever is already stored, a plain upsert, works fine with one editor. With more than one, it has no way to notice that the row changed underneath it between when it was loaded and when it was saved. The second write isn’t wrong on its own; it’s just missing the first person’s changes, and it looks identical to a normal, successful save. The team behind Rexfin found and fixed exactly this pattern on the headcount roster, where two editors working the same plan could overwrite each other through the save endpoint with no trace left behind.

How Rexfin catches it

The fix is optimistic locking: every plan record carries a version number. When you load a plan, you also silently pick up the version you’re looking at. When you save, that save is only allowed to succeed if the version on the server still matches the version you last saw. If someone else saved in between, the version has already moved, and your save is rejected as a conflict instead of being written over the top.

What matters is what happens next in the interface. A rejected save doesn’t fail quietly and doesn’t get silently retried into a partial success either. It surfaces a clear, hard-to-miss message: someone else has saved this in the meantime, and you need to reload before you can continue. That’s a deliberate choice, an interruption is a better outcome than a save that appears to work but has quietly dropped someone’s edits. If a record’s version data ever ends up in an inconsistent state, it’s designed to be self-healing rather than stuck: it loads with the plan cleared but the real version intact, so the next save repairs it instead of getting stuck in a permanent conflict loop.

Beyond the one form

Once this pattern was proven on headcount plans, the same class of save endpoint was checked more broadly across the product, and it turned up a second, similar lost-update case in compliance settings, where a save read the existing record, merged in a change, and wrote the whole thing back. That’s the same silent-overwrite risk under a different name, and it’s now scoped to only touch the specific field being changed rather than the whole record.

A few related edge cases came out of the same review. Two people creating a new named version around the same moment could otherwise collide on the name; creation now retries with a suffix so both saves land instead of one failing outright. Moving a department under a different parent had a narrow window where two simultaneous moves could combine into a genuine cycle, one department reporting into itself through others; that operation is now a single all-or-nothing transaction. And a subtler one: a brand-new record’s very first save used to be assigned the same version marker that meant “nothing here yet,” which meant the first edit after creating a plan could be overwritten just like an unprotected save would allow. New records now start at a version that can’t be confused with an empty one.

Where this sits in the workspace

This safeguard runs quietly underneath the parts of Rexfin a finance team touches every day. It’s what makes team workspaces safe to actually use with more than one editor at once, rather than an invitation to step on each other’s work. It pairs with the comments and review workflow, where discussion happens alongside edits rather than in a separate tool, and with the versioning and audit trail, which is where you’d look to see exactly what changed and when if a conflict ever prompts you to check. Together with the rest of the Rexfin product tour, it’s part of making a shared model something a team can actually work in at the same time, not just something they take turns touching.