Saltar al contenido

Automatización · Contenido y publicación

Publicar un artículo en Webflow con revisión y aprobación humana

Publica un artículo en Webflow: lee el esquema real, evita duplicados, crea un borrador y espera un sí explícito antes de llevarlo al sitio en vivo.

¿Cómo publico un artículo en Webflow sin duplicarlo ni sacarlo al aire antes de revisarlo?

El Met descubre el sitio y la colección correctos, lee el esquema real para usar los slugs y tipos de campo que sí existen y busca el slug propuesto antes de escribir. Si no hay otra entrada, crea el artículo siempre como borrador y vuelve a leerlo para mostrar el identificador, el locale, el slug, el estado y los campos que quedaron guardados. Ahí se detiene. Aunque la petición inicial diga «publícalo», solo continúa cuando una persona responde con un sí explícito en un mensaje nuevo. En ese momento relee el borrador, lo saca de ese estado, publica solo ese item y consulta su versión live en la API. Esa lectura confirma el estado de Webflow; no prueba que el HTML público, la caché o el CDN ya muestren el cambio.

Qué la pone en marcha

Cuando alguien lo pide

El equipo inicia la tarea por chat con el artículo y el sitio de destino. La ejecución crea un borrador y se detiene. La publicación solo se reanuda después, cuando una persona revisa el resumen de lo creado y responde con una aprobación explícita en un mensaje nuevo.

Una tarea de ejecución manual: alguien del equipo la corre con un botón, o se la pide al Met por chat.

Quién la ejecuta

Met de contenido y publicación en Webflow

Área de Marketing

No tiene nombre propio sembrado. Su trabajo no es diseñar el sitio ni decidir qué merece salir: es traducir un artículo aprobado al esquema que ya tiene el CMS, dejar evidencia del borrador y separar de forma deliberada la escritura de la publicación.

Qué hay que tener conectado

6 pasos · 9 herramientas

El procedimiento, paso a paso

Cada paso muestra la herramienta que se ejecuta. Son las del conector real: si una dejara de existir, esta página no compilaría.

  1. 1

    Descubrir el sitio correcto antes de tocar el CMS

    Si no hay un site_id configurado, el Met lista los sitios y no elige por intuición. Después lee el sitio elegido para mostrar su nombre, sus dominios y sus locales. Si hay más de un candidato, pide que una persona escoja. Esta receta trabaja solo sobre el locale principal: las tools actuales no permiten pasar cmsLocaleId al listar o volver a leer una entrada y por eso no ofrecen una comprobación segura para locales secundarios.

  2. 2

    Leer la colección y sus campos reales

    El listado ubica la colección por su displayName y devuelve su identificador. Luego la lectura del detalle trae cada campo con displayName, slug, tipo e isRequired. El fieldData se arma con esos slugs, no con los rótulos visibles ni con nombres inventados. Si falta un campo obligatorio o su tipo exige un identificador o una imagen que no se entregó, el Met se detiene antes de crear una entrada incompleta.

  3. 3

    Buscar el slug exacto para no duplicar el artículo

    Con el slug propuesto en minúsculas y separado por guiones, el Met consulta los items staged de la colección usando el filtro exacto por slug. Si aparece uno, lee ese item, muestra su id, estado y fieldData y se detiene para que una persona decida si el trabajo correcto es editarlo. No crea una variante con un sufijo ni toma dos títulos parecidos como si fueran entradas nuevas.

  4. 4

    Crear el item como borrador y mostrar qué quedó guardado

    Solo cuando el slug no existe llama webflow_create_item con isDraft true, isArchived false y el fieldData construido contra el esquema. Usa skip_invalid_files false para que una imagen o un archivo inválidos rechacen toda la creación en vez de desaparecer en silencio. Después vuelve a leer el id devuelto y presenta la colección, el locale principal, el nombre, el slug, isDraft y cada campo que quedó guardado. Si llevó una imagen, comprueba que el ImageRef tenga fileId o url y el alt aprobado. También enumera lo que se omitió, por ejemplo una imagen sin URL disponible. Todavía no hay una publicación ni se afirma que exista una dirección pública.

  5. 5

    Esperar un sí nuevo y reconciliar el borrador

    La respuesta inicial que pidió preparar o publicar no cuenta como la aprobación de este paso. El Met espera un mensaje nuevo y explícito después de mostrar el borrador. Si la persona pide cambios, actualiza solo los campos indicados y vuelve a mostrar el item; la aprobación anterior deja de aplicar. Antes de publicar relee el id para comprobar que sigue siendo el mismo borrador. Si una escritura devolvió error o quedó incierta, lista y lee primero: no repite a ciegas una operación que puede haber pasado.

  6. 6

    Publicar solo el item aprobado y verificar la API live

    Con el sí explícito, el Met usa webflow_update_item para pasar isDraft a false y después llama webflow_publish_items únicamente con el id aprobado y el booleano exacto confirmar true. No llama webflow_publish_site: esa acción publica el sitio o una página y podría sacar otros cambios staged. La respuesta se revisa por status, published_count, publishedItemIds y errors: el conteo sale de los ids confirmados, no de los solicitados. Un 202 sin esos datos queda unknown, no success. Finalmente webflow_get_item con live true comprueba que la versión live existe y muestra su estado. Si el resultado es partial, failed o unknown, vuelve a leer staged y live antes de decidir qué falta; no hay idempotencia, transacción ni rollback prometidos, y no se repite la publicación a ciegas.

Antes de empezar

Qué necesitas tener listo

Ninguno de estos puntos lo resuelve el Met. Si falta uno, la automatización se detiene ahí.

Los límites

Qué NO resuelve esta automatización

Preferimos decirlo aquí que descubrirlo en la implementación.

Preguntas frecuentes

Preguntas sobre esta automatización

Porque la API recibe slugs de campo, no los rótulos que ves en el diseñador, y además necesita respetar tipos y campos obligatorios. Leerlo evita enviar el cuerpo al campo equivocado o crear un borrador incompleto después de que alguien cambió la colección.

El Met la lee y se detiene. No crea un duplicado con un sufijo automático ni la sobrescribe. Editar esa entrada puede ser el siguiente encargo, pero requiere que una persona lo decida con el id y los campos actuales a la vista.

Porque la revisión necesita una evidencia que no existía en la petición inicial: el id, el slug, el estado y los campos que Webflow guardó. El segundo mensaje confirma ese resultado concreto, no una intención anterior a la escritura.

No para este flujo de CMS. La herramienta webflow_publish_items publica el item aprobado. La receta excluye webflow_publish_site porque esa acción tiene un alcance mayor y puede llevar al sitio otros cambios que estaban en preparación.

No. Demuestra que la API live devuelve ese item. No descarga la URL pública, no revisa el HTML ni comprueba la plantilla, la caché o el CDN. Esa verificación requiere otra capacidad.

No se vuelve a ejecutar todo. Primero se leen la versión staged y la live, y se revisan status, published_count, publishedItemIds y errors de la respuesta disponible. Con ese estado se decide si falta publicar o si el resultado ya existe. La receta no promete que repetir sea seguro ni que pueda revertirse.

Sigue por aquí

Otras automatizaciones con las mismas herramientas

¿Quieres esta automatización corriendo con tus datos?

Te la mostramos con tus cuentas conectadas, no con una demostración enlatada.