Two people, one record: how edits don't overwrite each other

The failure this page is about is quiet: two people open the same order, both edit, and the second save erases the first without anyone noticing until the invoice is wrong. Tabla's answer has two halves — keep everyone current, and refuse the write that would overwrite something its author never saw.

Their edits reach your screen

Every open table holds a live stream from the server. When a teammate edits, creates, deletes or restores a record, the change folds into your grid without a reload — your scroll position, selection and loaded rows all stay put. If the connection drops and comes back, the grid reloads once, so a gap can't leave you looking at stale rows.

Most of the time this is the whole story: you rarely collide, because you're rarely looking at something out of date.

The conflict moment

Every edit you make carries a token — the record's updated_at as your screen last saw it. The server compares it to the row's current state inside the write itself. If a teammate's edit landed in between, your write is refused whole, and the grid does two things at once: it adopts the current values, and the message says

Changed elsewhere — showing the latest. Edit not saved. Try again.

Your typed value is gone — deliberately. What's on screen is now the truth, and if your change still makes sense against it, you make it again in a second. No merge dialog, no lock, no "which version wins" screen: the losing write loses visibly, immediately, and cheaply.

The same net catches deletion: editing a record someone else has trashed gets "This record is in the trash. Edit not saved." and the row leaves your grid. And it catches undo — an undo that would overwrite a teammate's newer edit is skipped, because an undo is another write like any other.

Over the API

The same token is available to API callers, opt-in per record: send if_updated_at — the updated_at you last read — with an update. If the record changed since, the whole batch is refused with a 409, and the body carries the records as they are now, so your integration can heal without a second request:

{
  "error": {
    "code": "conflict",
    "message": "1 record changed since it was loaded.",
    "records": [
      { "id": "rec_5nwstwqxss6r", "updated_at": "2026-08-09T22:18:11.426Z",
        "created_at": "2026-08-09T22:18:11.381Z", "fields": { "…": "…" } }
    ]
  }
}

Omit if_updated_at and you get plain last-write-wins, unchanged. The full contract is in the API reference, and writing records over the API shows it in use.

Webhooks don't take sides

A webhook watching the table fires for every saved change, whoever made it — you, a teammate, an API key, an undo. There is no "my edits only" filter; the ledger records what happened to the data, not who was holding the keyboard. (Conditions can narrow which changes matter — see webhook conditions.)

One scope note: all of this is per record. Two people editing different fields of the same record in the same moment still conflict — the token guards the record, not the cell. In practice the live stream makes that window small.

The questions people ask

Does Tabla lock a record while someone edits it? No. Nobody waits for anybody; the write that arrives second against a changed record is the one that yields, out loud. Locks trade silent loss for silent waiting — this trades it for a visible retry.

Can I see who made the change I collided with? Yes — the record's Activity column names who changed which field, and what it was before. See Comments and activity.

Do my own two tabs collide? They can, by the same rules — a "session" is a tab. The same live stream keeps them current with each other, so in practice they behave like two polite colleagues.