How Do You Put a Review Step Before CMS Items Go Live?

How do you put a review step before CMS items go live?

By separating the act of creating an item from the act of publishing it, then giving those two actions to different people or different credentials. In the Webflow CMS that separation already exists in the data model, which means you are configuring something rather than building it.

This matters more every month, because the volume of drafts arriving in CMS collections is going up and a lot of them were not written by a person sitting in the Editor. A gate that was optional when one person wrote everything becomes necessary the moment drafting is fast and publishing is one call away.

What follows is the setup, step by step, for one specific situation: you have a Webflow CMS collection, more than one person or process can add items to it, and you want a human to see each one before it appears on the live site.

What does draft actually mean in the Webflow CMS?

It means the item exists in your collection but is not on the live site. Webflow's documentation for creating items describes the draft flag directly, saying that a new item has never been published, so setting the draft flag to true gives it a Draft status, and setting it to false queues the item to publish on the next site publish.

Read that second half carefully, because it is the part people get wrong. Turning the draft flag off does not publish the item on its own. It queues it. Publishing is a separate action with its own endpoint, and Webflow documents that endpoint as publishing an item or multiple items, taking a list of item identifiers.

So there are three states worth naming, not two. An item can be a draft that nobody intends to publish yet, an item can be ready and queued, and an item can be live. Your review step sits between the first and the second, which is a more precise place to put it than most people realise.

One practical warning before you build anything. I would set the draft flag explicitly on every create call rather than relying on a default, because the behaviour you want should be stated in your request rather than inherited. Being explicit costs you one line and removes an entire class of surprise.

How do you set up the gate itself?

Three steps, and the first one is the whole gate. Step one: make every path that creates items set the draft flag to true. Whether that is a person in the Editor, a form, a migration script, or an agent, nothing arrives ready to publish. That single rule is the review step.

Step two: give the creating process only what it needs to create. Webflow separates read and write on the CMS as distinct scopes, so a process that drafts needs the write scope, and that write scope is also what publishing uses. That means the separation you want is not always available at the permission layer alone, and the rule about always creating as a draft is doing the real work.

Step three: make publishing a deliberate, separate action taken by a named person. Webflow's publish endpoint takes a list of item identifiers, which means whoever publishes has to say exactly which items they mean. That is a feature, not friction. Publishing by enumeration forces a decision per item instead of a sweep.

If you are creating items in bulk, note the shape of the endpoint while you are designing this. Webflow documents the create endpoint as handling up to one hundred items in a request, which is convenient for a migration and dangerous for a review queue. I cap my own batches far below that, because a reviewer facing one hundred new drafts will approve them as a block, which is not review.

Who should hold the publish permission?

A person, not a pipeline, for anything that represents your business publicly. That is a judgement rather than a technical requirement, and I hold it fairly firmly.

The reason is asymmetry. A bad draft costs nothing, because nobody sees it. A bad publish is public, and depending on what it said, it can be quoted, cached, and repeated somewhere you cannot reach. The cost of the two mistakes is not remotely equal, so the permissions should not be equal either.

Where a platform gives you finer control, use it. Webflow's scope list separates branch operations into six distinct permissions including a dedicated publish permission, which is a good model for what granular looks like when a vendor takes it seriously. Grant the ability to prepare freely and the ability to release narrowly.

If you are handing any of this to an automation, decide the permission question before you build the workflow rather than after, because retrofitting a narrower credential is much harder than starting with one. I have written the longer argument in how narrow an agent's credential should be.

What should the reviewer actually check?

Four things, in this order, and nothing else. Anything more and the review becomes an edit, which is how review steps die.

First, is every checkable claim traceable. Not whether it sounds right, whether the reviewer could produce the source. Second, is the link set correct, meaning every internal link points at a page that exists and every external link goes where the text says it goes. Third, does the title match the content, because a mismatch here is the single most common cause of a page that gets impressions and no clicks.

Fourth, and this is the one people forget, is the slug right. A slug is the hardest thing to change after publishing, because changing it breaks every link that already pointed at the old one. Everything else on a page can be corrected in place. The address cannot, cheaply, so it deserves a deliberate look while the item is still a draft.

Write those four down as the review, and resist adding a fifth. A reviewer with four criteria reviews. A reviewer with twelve criteria skims and approves, which is worse than no review because it creates the appearance of one. The same principle drives a weekly content QA checklist in Airtable, which is the batch version of this same job.

How do you handle something that is already live and wrong?

Take it back to draft rather than deleting it. Webflow's unpublish operation is documented as removing items from the live site and reverting them to draft, handling up to one hundred live items per call. The content survives, the item survives, and only the public version goes away.

That is almost always what you want in an emergency. Deleting destroys the record and breaks every inbound link permanently. Unpublishing buys you time to fix the thing properly and republish the same item at the same address, which keeps every reference intact.

There is also an in-between move worth knowing. Webflow's update operation treats the draft flag as three-valued in practice: setting it to true marks an item as a draft, setting it to false marks it ready to publish, and omitting it preserves whatever status the item already had. Omitting it is the safe default when you are correcting content and do not want to change publication state by accident.

Build the unpublish step into your process before you need it, including who is allowed to run it and how it gets recorded. An emergency is the wrong moment to be discovering which credential can take a page down.

What changes when an agent is doing the drafting?

The gate matters more and the review has to get more specific, because the failure mode changes. A tired human writes something vague. A confident system writes something precise and wrong, which is considerably harder to catch by skimming.

So I would add one check to the four above when the draft was machine-authored: does every number, date, version, and named company in this piece trace to a source, and is that source the company's own page rather than an article about it. That check catches the specific error mode, and it does not slow down a human-written draft much because human writers produce fewer confident specifics.

I would also keep the drafting and the reviewing on different credentials even when the same person supervises both. It is not about distrust, it is about making the two actions distinguishable in whatever record you keep afterwards. If everything happened under one token, your log tells you that the token did things, which is not the same as knowing what was reviewed.

The workflow shape that has held up best for me is simple. The agent creates drafts and can never publish. A person reads and publishes by naming items. Nothing else is automated, and the boring bit is deliberately the bit a human does. The broader version of this pattern is in having agents work in CMS drafts.

How do you stop the review step becoming a bottleneck?

Make the queue small and the criteria fixed. A review step fails for one of two reasons: too many items arrive at once, or the reviewer does not know when they are finished. Both are solvable and neither is solved by working harder.

Cap the batch. If your process can produce forty drafts, release them to review in smaller groups on a schedule rather than all at once. A reviewer who sees five items reads five items. A reviewer who sees forty picks a few at random and approves the rest, and you have bought yourself the illusion of a gate.

Then make the finish line explicit. The four checks are the review. When they pass, publish. There is no additional standard of general goodness to satisfy, and inviting one is how a review step turns into an editing queue with no end.

Finally, measure the wait. If drafts sit for more than a couple of days, your bottleneck is real and the answer is usually to reduce what arrives rather than to loosen the gate. Publishing less and reviewing properly beats publishing everything and reviewing nothing, and that trade is worth making explicitly rather than by drift.

What should you do next?

Go and check one thing today: whether anything in your setup can create a CMS item that is not a draft. Look at your integrations, your forms, your scripts, and anything an agent runs. If any of them can create a publishable item, that is your gap and it is a one-line fix in most cases.

Then write your four review criteria somewhere the reviewer will see them, and name the person who holds the publish action. Two sentences of documentation do more here than any amount of tooling, because the failure is almost never technical. It is that nobody was sure whose job it was.

If you are setting this up on a collection that already has a lot of items, or you want a second pair of eyes on a workflow where an automation writes and a person approves, reach out. It is usually a short conversation and the setup takes an afternoon.