What breaks when two people edit the same CMS item?

What happens when two people edit the same CMS item?

Usually one set of changes survives and nobody finds out which. The dangerous part is not the collision, it is the silence. Nothing in a normal publishing day tells you that an edit was overwritten, so the loss gets discovered weeks later by a reader rather than by you.

This gets worse the moment anything automated writes to the same collection, because an automation edits faster than a person can notice. If a script and a human are both touching the same item, the human will almost always lose and will almost always assume they made a mistake.

So this is about what the platform actually exposes, what you can genuinely detect, and the process that prevents the problem rather than the tooling that promises to.

Why is the staged and live distinction the first thing to understand?

Because an item can be in two states at once, and most confusion about lost edits is really confusion about which state someone was looking at. Webflow's developer documentation says the Data API supports both staged and live content, giving precise control over the publishing workflow.

That means a change can exist on the staged item without being visible on the live site. A person who edits, checks the public page, sees nothing and edits again has not been ignored. They were looking at the wrong copy.

Once you hold that distinction clearly, a lot of reported bugs resolve themselves. The question is never just "did my change save", it is "did my change save, and has it been published". Those are two separate events with two separate timestamps. Treating them as one event is where most of the confusion starts.

Which timestamps actually tell you something?

Three, and they are on every item. Created, last updated and last published. Together they answer most questions about what happened and when, which makes them the first thing to look at when an edit seems to have vanished.

The useful pattern is the gap between last updated and last published. If an item was updated after it was last published, the staged version differs from the live one, and that is either intentional or the explanation for the complaint you just received.

A newly created item has no published timestamp at all until it is published, which is a clean way to distinguish something that has never gone live from something that went live and was then changed. Those two situations need different responses and they look identical if you only read the update time.

How does an automated write make this worse?

By being fast, regular and invisible. A person who overwrites someone's work usually notices something odd. A scheduled job does not notice anything, and it will do the same thing again tomorrow.

The mitigation is to be deliberate about which fields an automation is allowed to touch. If a script only ever writes the fields it owns, and a human only ever writes the fields they own, most collisions stop being possible at all. That is a design decision rather than a technical control, which means it has to be written down somewhere.

It also means being careful about what you send in an update. An update carries whatever fields you include, so a job that helpfully rewrites every field will overwrite human edits in fields it had no business touching.

What does the update contract actually do to status?

It preserves status unless you tell it otherwise, which is a genuinely helpful default. Webflow's own update interface documents that the draft flag is true for Draft, false for Ready to Publish, and that omitting it preserves the item's existing status.

That single behaviour prevents a common accident. A job that updates one field on a draft item will not accidentally mark it ready, provided it simply leaves that flag out. Any automation that sets the flag explicitly on every write is taking a decision it probably does not intend to take.

Publishing has a similarly explicit contract. When you publish, the response comes back with a list of item IDs that were published and a separate errors array, which means a partial success is distinguishable from a full one. Reading that response rather than assuming it worked is the difference between knowing your content is live and hoping.

How do you find out that something changed?

Subscribe to the change rather than checking for it. Webflow's webhook triggers include item created, item changed, item deleted, item published and item unpublished, which covers every event that matters for detecting a collision.

An item changed webhook writing to a simple log is the cheapest possible audit trail. You do not need to act on it automatically. You just need the ability to answer, after the fact, who or what touched an item and when. That single log turns an unanswerable argument into a five minute lookup.

Webflow also documents rate limits for its API and names webhooks as the way to optimise API usage, which is a second reason to prefer being notified over polling. I am not going to quote limit numbers here because they change, and the only ones worth acting on are the ones on Webflow's own reference page today.

Why is changing a slug the most dangerous edit?

Because it is the one edit whose damage extends beyond the item. Webflow's own interface documentation states plainly that a slug must be unique within the collection and that changing it breaks all links referencing the old slug.

That makes a slug edit categorically different from a content edit. If two people disagree about a headline, the worst case is a headline you have to fix. If two people disagree about a slug, you have broken inbound links, internal links and anything anyone bookmarked.

My rule is that slugs are decided once and then treated as immutable unless there is a redirect plan attached to the change. That is a policy rather than a platform constraint, and it is the single highest value policy you can adopt about a CMS. It is also part of why the shape of your content model matters so much, which I went into in which Webflow CMS constraints should shape your content model.

What process actually prevents this?

Field ownership and a single publishing moment. Decide which fields belong to people and which belong to machines, then decide who is allowed to publish, and let everyone else stage.

The second half matters more than it sounds. If several people can publish independently, you get partial states going live at unpredictable times. If publishing is one deliberate act by one owner, collisions surface before they reach readers, because the owner is looking at the staged item when they press the button.

For larger coordinated changes the right answer is to stage everything together rather than piecemeal, which is what single page and staged publishing workflows are for. I have looked at that shift in what single page publishing changes.

What should you check after a suspected collision?

Compare the last updated time against the last published time, then look at your change log for that window. Those two checks resolve most cases in a couple of minutes.

If the log shows two writes close together from different sources, you have your answer and you also have a process problem to fix rather than a mystery. If the log shows one write, the missing change was probably never saved, which is a different conversation and a kinder one.

What I would avoid is relying on anyone's memory of what they typed. Across more than 70 projects for more than 25 clients over more than six years, recollection of edits has been wrong often enough that I treat it as a hypothesis rather than evidence. The same applies whenever two systems disagree about anything, which I have written about in what to do when two tools disagree about a number.

What should you do next?

Write one short document listing every field in your main collection and who owns it: a person, a specific automation, or nobody. That document takes twenty minutes and prevents most of what this article describes.

Then set up a webhook on item changed, pointed at anything that keeps a log. You will not look at it for weeks and then one day it will answer a question that would otherwise have been unanswerable.

If you have automations and people writing to the same collection and you want a second opinion on where the collisions are likely, reach out. It is usually one or two fields doing all the damage.