Skip to content

Automation · Content and publishing

Publish a Webflow article with human review and approval

Publish an article in Webflow CMS: read the real schema, avoid duplicates, create the draft, and wait for explicit approval before taking it live.

How do I publish a Webflow article without duplicating it or taking it live before review?

The Met discovers the right site and collection, reads the real schema so it uses field slugs and types that actually exist, and searches for the proposed slug before writing. If there is no other item, it always creates the article as a draft and reads it again to show the identifier, locale, slug, state, and stored fields. It stops there. Even when the initial request says "publish it", it continues only after a person sends an explicit yes in a new message. At that point it rereads the draft, takes it out of draft state, publishes only that item, and queries its live version in the API. That read confirms Webflow's API state. It does not prove that the public HTML, cache, or CDN already shows the change.

What starts it

When someone asks for it

The team starts the task in chat with the article and destination site. The run creates a draft and stops. Publishing resumes only after a person reviews the summary of what was created and sends explicit approval in a new message.

A manual task: someone on the team runs it with a button, or asks the Met for it in chat.

Who runs it

Met for content and Webflow publishing

Social team

It has no seeded name. Its job is not to design the site or decide what deserves to ship. It translates an approved article into the CMS schema that already exists, leaves evidence of the draft, and deliberately separates writing from publishing.

What you need connected

6 steps · 9 tools

The procedure, step by step

Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.

  1. 1

    Discover the right site before touching the CMS

    When there is no configured site_id, the Met lists sites and does not choose by instinct. It then reads the selected site to show its name, domains, and locales. If several candidates remain, it asks a person to choose. This recipe works only in the primary locale. The current tools cannot pass cmsLocaleId when listing or reading an item, so they cannot safely verify a secondary-locale item.

  2. 2

    Read the collection and its real fields

    The listing locates the collection by displayName and returns its identifier. The detail read then returns every field with displayName, slug, type, and isRequired. fieldData is built from those slugs rather than visible labels or invented names. If a required field is missing or its type needs an identifier or image that was not supplied, the Met stops before creating an incomplete item.

  3. 3

    Search the exact slug to avoid a duplicate article

    Using the proposed lowercase, hyphen-separated slug, the Met queries the staged items in the collection with the exact slug filter. If one appears, it reads that item, shows its id, state, and fieldData, and stops so a person can decide whether editing is the right task. It does not create a suffixed variant or treat similar titles as proof that two items are different.

  4. 4

    Create the item as a draft and show what was stored

    Only when the slug does not exist does it call webflow_create_item with isDraft true, isArchived false, skip_invalid_files false, and fieldData built against the schema. That setting makes an invalid image or file reject the entire create instead of disappearing silently. It reads the returned id and shows the collection, primary locale, name, slug, isDraft, and every stored field. When an image was mapped, it verifies that ImageRef contains fileId or url and the approved alt. It also lists what was omitted, such as an image with no available URL. Nothing is published yet, and it does not claim that a public address exists.

  5. 5

    Wait for a new yes and reconcile the draft

    The initial request to prepare or publish does not count as approval for this step. The Met waits for a new, explicit message after showing the draft. If the person requests changes, it updates only those fields and shows the item again. Earlier approval no longer applies. Before publishing, it rereads the id to confirm it is still the same draft. If a write returned an error or uncertain result, it lists and reads first. It does not blindly replay an operation that may have succeeded.

  6. 6

    Publish only the approved item and verify the live API

    With explicit approval, the Met uses webflow_update_item to set isDraft to false and then calls webflow_publish_items with only the approved id and the exact confirm flag set to true. It does not call webflow_publish_site. That action publishes a site or page and could ship other staged changes. The response is checked through status, published_count, publishedItemIds, and errors. The count comes from confirmed ids, not requested ids. A 202 without those details is unknown, not success. Finally, webflow_get_item with live true confirms that a live version exists and shows its state. When the result is partial, failed, or unknown, it reads staged and live before deciding what remains. No idempotency, transaction, or rollback is promised, and publishing is not blindly repeated.

Before you start

What you need ready

The Met solves none of these for you. If one is missing, the automation stops there.

The limits

What this automation does NOT solve

Better said here than discovered halfway through the rollout.

FAQ

Questions about this automation

The API receives field slugs rather than the labels shown in the Designer, and it must also respect types and required fields. Reading the schema avoids sending the body into the wrong field or creating an incomplete draft after somebody changes the collection.

The Met reads it and stops. It does not create a duplicate with an automatic suffix or overwrite it. Editing that item can be the next task, but a person must decide with the id and current fields in view.

Review needs evidence that did not exist in the initial request: the id, slug, state, and fields Webflow stored. The second message approves that concrete result rather than an intent expressed before the write.

Not for this CMS flow. webflow_publish_items publishes the approved item. The recipe excludes webflow_publish_site because that action has a broader scope and may take other staged changes live.

No. It proves that the live API returns the item. It does not download the public URL, inspect HTML, or check the template, cache, or CDN. That verification needs another capability.

The whole flow is not replayed. It first reads the staged and live versions and checks any available status, published_count, publishedItemIds, and errors. That state determines whether publishing is still missing or the result already exists. The recipe does not promise a safe repeat or reversal.

Keep going

Other automations built on the same tools

Want this automation running on your own data?

We will show it to you with your accounts connected, not with a canned demo.