The lost update: when two automations overwrite the same record
Two workflows touch the same contact in the same instant, each writes the whole record back, and one change vanishes without a trace. Why it happens and how to stop your automations from deleting each other's work.
A field got filled in, then unfilled itself, and nothing logged an error
A client ran two automations against the same CRM contact. One looked up company size from a data provider and wrote it onto the record. The other moved a contact's lifecycle stage forward whenever they submitted a form. Both had been running quietly for months.
One morning an existing lead filled in a form at almost the same instant the nightly enrichment caught up to their record. Both workflows grabbed the same contact within a second or two of each other. The enrichment read the record, added the company size, and wrote the whole contact back. A second later the form automation also wrote the whole contact back, with the new lifecycle stage but with the old, empty company size, because it had read the record before the enrichment ran. The company size that had just been filled in was gone. No error, no warning, just overwritten.
This is the lost update, and it is an old problem
What happened has a name database people have used for decades: the lost update. Almost every workflow does the same three steps without thinking about them. Read, change, write back. As long as only one process does this, everything is fine. The moment two processes read, change, and write back the same record in the same window, the one that writes last wins. And "wins" means it overwrites the other's change with a version that was already stale when it was read.
This is not an exotic edge case. It happens whenever two triggers land close together by chance. That is what makes it so slippery. It never shows up in testing, because you run cases one at a time. In production it shows up rarely but regularly, and each time a piece of information quietly disappears.
Why no-code makes it worse
If you write software by hand, you can tell the database to change one field and leave the rest alone. Most no-code modules cannot do that cleanly. They pull the full record, you map a few fields, and the module writes the full record back, including every field you never touched. Every write is a full snapshot that paints over whatever someone else changed in the meantime.
On top of that, the individual workflows know nothing about each other. Each one feels like a self-contained little program. You cannot tell from looking at a single scenario that the CRM record is shared memory that several processes reach into at once. So you build each workflow as if it were alone with the data.
How you even notice
The insidious part is that nothing points to a fault. Both workflows report success, both runs sit green in the log. It only becomes visible when someone notices that a field that was filled in yesterday is empty again today. Dig into the record's history and you often find two writes a few seconds apart, with the second carrying the old value. That pattern, a field that seems to reset itself, is the telltale sign. When a colleague says a value keeps disappearing, it is worth checking which automations write to the same record.
Four ways to prevent it
Write only the field you changed. If the API supports a partial update, company size instead of the whole contact, then two workflows touching different fields never collide in the first place. That alone solves the most common version of the problem.
Give every field exactly one owner. If only one workflow ever writes company size and only one ever writes lifecycle stage, neither can stomp on the other. Clear ownership at the field level is the simplest organizational fix, and it costs nothing but discipline.
Serialize writes to the same record. Instead of several workflows writing straight into the CRM, route all their changes through a queue that processes them one after another. Then there is no "at the same instant" left.
Use a version check when the other side offers one. Some APIs remember which version of the record you read and reject your write if the record changed since then. You get an error instead of a silent overwrite, and you can re-read the record and reapply your change.
This is not the same as idempotency
The two get mixed up a lot. Idempotency protects you from processing the same trigger twice, like a webhook that arrives in duplicate. This is something else: two different triggers that happen to touch the same record at the same time. Idempotent processing does nothing for the lost update, because both writes are perfectly correct on their own. They just get in each other's way.
The pattern underneath
This comes back to an assumption too. A workflow feels isolated, but it is not. It shares its records with every other workflow that touches the same objects, often ones built somewhere else that nobody remembers anymore. When you build a new automation, do not only ask what it should do. Ask who else writes to the same fields. The missing company size went unnoticed because nothing broke. Something was just no longer there that had been there a moment before.