Workflows

Un workflow encadena pasos en una automatización que llevan a cabo tus agents: leer una tabla, llamar a un agent, ramificar según el resultado, iterar sobre una lista. Lo construyes en un lienzo, conectas los pasos entre sí y lo publicas como una versión inmutable — la misma forma que tiene un agent: un draft que editas y una versión publicada que se ejecuta.

Esta página describe el editor visual: la lista, el lienzo y el selector de pasos, cómo se configura un nodo, el autoguardado y la publicación, y las rutas de teclado por todo ello. El editor está en Workflows en la consola. La página de lista de Workflows tiene un "?" que reproduce un recorrido por esa lista; el editor en sí no tiene recorrido.

Crear y duplicar un workflow

New workflow solicita un nombre y quién puede usarlo, con el mismo selector que al crear un agente: todos, solo tú o personas y departamentos elegidos. Elige el disparador, añade opcionalmente descripción y etiquetas y pulsa Create. Elegir un disparador no crea el flujo. Workflow templates abre una galería de categorías separada; elegir una plantilla abre el formulario con su nombre y descripción completos.

El catálogo reúne las tarjetas y la búsqueda en un panel. Filters muestra estado, etiquetas y orden, junto al número de filtros activos. Un fallo de carga ofrece Retry en lugar de un catálogo vacío. La importación empieza eligiendo un archivo; Or paste the file's JSON here abre un campo de texto con etiqueta.

La lista muestra cada workflow que puedes ver como una tarjeta: su estado, quién puede alcanzarlo, si tiene una versión en vivo y cuándo se editó por última vez. Filter by status la acota a los Drafts que aún estás construyendo, los Published que se ejecutan o los Archived. Desde una tarjeta abres el editor, los runs del workflow o una copia.

Duplicate copia el draft actual de un workflow en uno nuevo llamado {name} (copy). Un duplicado es un workflow nuevo con su propio draft, nunca una copia de una versión publicada.

Una lista vacía puede ser un filtro, no una organización vacía

No workflows yet y Nothing matches son estados distintos: el primero es una organización sin ninguno, el segundo un filtro de estado bajo el que no cae ninguna fila. Clear filter devuelve la lista completa. Un workflow compartido contigo aparece en la misma lista en cuanto tienes workflows:view.

Plantillas, exportar e importar

Las automatizaciones listas para ejecutar son Public API → table y Markdown notebook. El servidor prepara una tabla y un borrador completamente configurado en una transacción. Ambos son privados por defecto; una audiencia elegida explícitamente se aplica al flujo y a su tabla. No hace falta elegir cuenta, clave API ni tabla. El primer ejemplo obtiene una publicación de JSONPlaceholder y guarda su título y contenido; el segundo escribe una nota Markdown. Los runs siguientes reutilizan la tabla y actualizan el mismo registro de ejemplo. Crearlos requiere permisos para crear y editar tablas. Starter y Two-step sequence siguen siendo pequeños ejemplos locales.

El historial ocupa automáticamente el espacio disponible de la página, sin un control para ampliarlo. El catálogo ocupa el espacio disponible y ofrece su propio botón de pantalla completa. Solo muestra paginación si hay más páginas. La importación ofrece una zona etiquetada para seleccionar o soltar un archivo JSON.

La paginación del historial está al pie del panel. Los detalles de un run tienen un resumen compacto, una canvas que ocupa el espacio de trabajo y un panel lateral con Steps, Output y archivos disponibles. Pulsa un paso para consultar sus datos guardados. Importar un archivo y pegar JSON tienen pestañas separadas; el campo de código JSON ofrece formato y conserva el contenido si no es válido.

Export workflow, en More en la cabecera del editor, exporta el borrador como un archivo .workflow.json. El archivo no lleva ningún id de este despliegue: cada agent, tabla, secreto, miembro, bot o workflow que eligió un paso queda fuera y listado, los datos de prueba fijados quedan fuera y también el workflow de errores. Nunca contiene el valor de un secreto.

Import en la lista crea un borrador nuevo a partir de ese archivo, quita cualquier id que uno hecho a mano todavía nombre, y lista cada paso y campo que hay que volver a elegir antes de publicar. Un archivo con un paso que este despliegue no tiene se rechaza, y no se crea nada.

Encontrar, nombrar y retirar un workflow

Cada tarjeta dice qué inicia el workflow y cuántos pasos tiene, si está en vivo o es un borrador, y cómo y cuándo fue su última ejecución - la fecha de edición hasta que se ejecute.

Sobre las tarjetas, una búsqueda encuentra un workflow por su nombre, descripción o etiquetas, un filtro de etiquetas acota la lista a una, y el orden es la última edición, el nombre o los más nuevos primero. Todo se guarda en la dirección, así que recargar o un enlace compartido muestran la misma lista.

More → Settings contiene el nombre, la descripción, las etiquetas y los ajustes de ejecución; los cambios se guardan automáticamente. El editor ocupa la ventana disponible: Input a la izquierda, Parameters y Settings en el centro y Output a la derecha. Los disparadores usan dos paneles porque no reciben datos anteriores. En pantallas grandes cada panel se desplaza por separado; en móviles hay una columna. Las ejecuciones guardadas muestran sus parámetros de solo lectura junto a sus datos. Los valores del registro usan los nombres de las columnas. Las notas ofrecen Open note, tamaños y controles para redimensionar.

El selector muestra servidores del catálogo MCP antes de conectarlos; la entrada genérica Call an MCP tool está oculta. Conecta un servicio y elige una de sus herramientas descubiertas. Se mantiene la lista de herramientas permitidas. Los pasos de colores y el minimapa están activos por defecto. Los pasos de modelos muestran instrucciones, temperatura y esfuerzo; los ajustes vacíos conservan los valores del proveedor. Jev muestra modelo, pregunta y umbral de confianza. Send an email usa el remitente de la plataforma o conecta Gmail u Outlook y, tras confirmar, cambia a la herramienta MCP real del buzón. El cambio elimina asignaciones incompatibles y se puede deshacer.

El paso Send an email también ofrece SMTP account → New SMTP account. Guarda servidor, puerto, usuario, contraseña y remitente en el diálogo del vault. STARTTLS suele usar 587 y TLS implícito 465; ambos verifican certificados. El workflow solo guarda smtp_secret_id. Platform sender elimina la selección. La publicación y cada ejecución comprueban el acceso al secreto; una cuenta no disponible detiene el paso en lugar de cambiar de remitente.

HTTP request, upload y download comparten el panel Authentication: sin autenticación, Bearer, clave API en un encabezado, clave API en un parámetro URL o Basic Auth. Elige un HTTP credential del vault o créalo en el paso; el origen permitido se sugiere a partir de su URL. El workflow solo guarda auth.secret_id. Los encabezados personalizados y prefijos opcionales admiten, por ejemplo, Authorization: Token …. Basic Auth usa el usuario y token del vault como usuario y contraseña. Cambiar de método elimina ajustes incompatibles y conserva la referencia; desactivar la autenticación elimina también la referencia.

La búsqueda de aplicaciones también consulta el registro MCP replicado, incluidos los servicios aún no conectados. Un servidor conectado sin inventario ofrece Refresh tools a quienes administran conexiones. Los pasos de canales permiten crear y seleccionar una cuenta de bot dentro del workflow; solo los miembros con permiso para administrar canales ven esta acción.

El Architect puede descubrir el catálogo de pasos, crear y modificar borradores privados de workflows, probarlos y revisar los resultados de los runs. También crea Virtual Tables tipadas y consulta o actualiza registros. Los skills workflow-builder y virtual-tables explican cuándo usar estas funciones. Si un servicio no aparece en la galería MCP, el Architect puede envolver su API documentada con un paso HTTP request y ofrecer un workflow publicado e invocable como herramienta de un agente mediante las herramientas de AgenticOS MCP. Las credenciales permanecen en la bóveda. Las pruebas pueden realizar acciones reales; publicar con autoridad humana retenida sigue requiriendo una sesión humana.

Bajo su nombre el editor dice dónde está el workflow: Draft, not published, o Live · version 3, con Unpublished changes al lado cuando el borrador difiere de esa versión en algo que publicar llevaría. Mover un paso o fijar datos de prueba no cuenta.

Un workflow publicado cuyo disparador funciona solo - un webhook, una programación o un nuevo registro de tabla - tiene un interruptor Active en la cabecera del editor, y su tarjeta dice Active o Paused. Apagarlo pausa el disparador al momento; encenderlo lo reanuda como quien lo publicó, así que requiere permiso para ejecutar el workflow. El menú ... de una tarjeta archiva un workflow, lo que también pausa su disparador. Uno archivado se puede restaurar, todavía en pausa, o eliminar con sus versiones, ejecuciones y permisos compartidos; uno cuyas ejecuciones no han terminado se rechaza con WORKFLOW_IN_USE.

Los pasos de agentes conservan conversaciones privadas para el historial del modelo y los espacios de trabajo vinculados a la conversación. Los turnos del chat reutilizan el contexto del paso; el chat visible recibe solo el resultado del flujo. Los chats de prueba tienen sesiones aisladas y un nuevo chat de prueba reinicia el contexto. Las conversaciones internas no aparecen en la lista de chats y se eliminan junto con su flujo o chat de origen.

Los agentes llamados desde flujos pueden usar sus herramientas de AgenticOS MCP tanto en el worker en segundo plano como en el chat web.

El lienzo y cómo añadir pasos

El editor mantiene visibles Runs, Test draft y Publish. More contiene Versions y el cambio entre edición y lectura. Canvas options reúne minimapa, estilo de conexión y atajos. Un paso sin conexión entrante omite el panel Input vacío y deja más espacio a los parámetros; Expected output fields despliega el esquema de salida. Review setup before testing muestra la configuración pendiente.

El lienzo es donde aparecen los pasos y las conexiones de un workflow, y tiene todo el ancho del editor bajo la cabecera. Un nodo es un paso; una arista es una conexión que fija el orden: el paso al que apunta se ejecuta después del paso del que sale.

Cada nodo es una tarjeta con el icono del paso, su nombre y una línea debajo: lo que está configurado para hacer - una condición, una URL, el número de campos mapeados - y, antes, el agente, el modelo o la tabla con los que trabaja. Un paso con más de una salida nombra sus puertos: true y false, Each item y Done, y un puerto Error rojo en un paso que gestiona sus errores. Un paso que bloquea la publicación lleva una marca de configuración (roja tras intentar probar o publicar): al pasar el ratón por encima lista los primeros problemas, y un clic abre el paso.

Un trackpad o la rueda del ratón mueve el lienzo, y un pellizco - o Ctrl o Cmd con la rueda - lo amplía; sus controles están en la esquina.

Los pasos se eligen en el selector de pasos. Muestra secciones - Start, AI, Flow, Data, Apps and the web - con sus grupos debajo. Un grupo como Slack, Tables o Jev decisions se abre a sus pasos, y un grupo de un solo paso es ese paso. Search steps encuentra cualquier paso por su nombre, por lo que hace o por su grupo. Añades un paso de cuatro maneras:

• + arriba a la izquierda del lienzo - o Add step en el centro de un lienzo vacío - abre el selector. El paso va tras el paso seleccionado, o al final del flujo a la vista, conectado a él cuando sus puertos encajan. Un paso de inicio va en cambio antes del inicio actual y pasa a serlo.
• + junto a la salida de un paso abre el selector para el paso que va tras esa salida.
• Clic derecho en el lienzo: el mismo selector se abre donde hiciste clic, y el paso aparece allí. Debajo, Add a note y, cuando hay algo copiado, Paste.
• Arrastra un paso desde el selector para dejarlo donde lo sueltes, sin conectar.

Las aplicaciones de Google Workspace (Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets) y de Microsoft 365 (Outlook, Outlook Calendar, OneDrive, Excel) son grupos propios en Apps and the web. Cada uno contiene el trigger nativo de la aplicación, donde el lienzo puede aceptar uno, y una entrada por herramienta de cada conexión MCP de la organización al servidor correspondiente - como Create draft o Send message.

Las herramientas de una conexión se reparten en estos grupos por su nombre; una herramienta que ninguno reclama queda en el grupo del propio servidor (Google Workspace, Microsoft 365), donde también se muestran Connect y una conexión sin probar. Las herramientas de inicio de sesión (start_google_auth, login, verify-login) no se ofrecen.

Elegir una entrada añade un MCP call ya configurado con esa conexión y esa herramienta, así que los workflows guardados y el contrato del nodo no cambian. La entrada no oculta nada: lleva una insignia MCP y el nombre de la conexión, el nombre propio de la herramienta va debajo, en su propia línea, y el servidor se nombra una vez en el encabezado del grupo; nada se recorta.

Search steps la encuentra por cualquiera de los dos nombres o por la aplicación. En el lienzo el paso se lee Gmail · Create draft con una insignia MCP, y debajo se ven la conexión y el nombre propio de la herramienta; sus ajustes dicen que es una llamada a una herramienta MCP en esa conexión y enlazan a ella. Una herramienta que la lista no nombra muestra su propio nombre. Cada herramienta de Gmail que ofrece el servidor tiene un nombre claro, como List labels o Read thread. El trigger nativo no es una llamada MCP y no lleva insignia.

Sin una conexión que encaje, el grupo del propio servidor muestra una fila Connect para conectar el servidor. Solo se listan las conexiones de la organización, y las herramientas de una conexión son las que registró su última prueba, así que vuelve a probarla para listar las nuevas. Quien no puede editar el workflow ve solo los triggers. Quien lo edita pero no gestiona servidores MCP ve todas las acciones y no recibe una fila Connect: solo quien gestiona servidores conecta uno. Las filas de acciones de una aplicación se eligen, no se arrastran: solo las filas propias de un paso se pueden arrastrar al lienzo.

Un paso nuevo nunca cae encima de otro, queda seleccionado, abre sus ajustes cuando tiene alguno, y el lienzo se desplaza hasta él cuando queda fuera de la vista. Dentro del cuerpo de un bucle cada paso nuevo se conecta al cuerpo, así que se queda ahí. El selector muestra lo que es válido donde estás: Loop item y Loop result solo dentro del cuerpo de un bucle, y un bucle mientras los bucles no estén anidados tan hondo como permite la publicación.

Un clic derecho en un paso ofrece Open settings, Duplicate, Switch off y Delete step. Con varios pasos seleccionados, una barra abajo los borra juntos.

Switch to view only, en la cabecera, enseña a quien puede editar el workflow lo que ve un lector: nada en el lienzo se mueve, se conecta ni se borra, un paso se abre en solo lectura con un clic, y Test draft y Publish desaparecen. Switch to editing lo devuelve a la edición, y el editor siempre se abre en modo de edición. Un guardado aún en curso termina en ambos casos.

El catálogo de pasos crece con el tiempo

El selector se alimenta de los nodos registrados en el despliegue, no de una lista fija. Un tipo de nodo registrado más tarde aparece en él en cuanto se registra, sin cambiar un workflow que ya construiste.

Notas, orden y atajos

Add a note bajo el selector que abre un clic derecho pone una nota junto a los pasos: markdown, escrita con doble clic o con su lápiz, movida arrastrando y redimensionada desde sus esquinas; seleccionada, su botón de paleta despliega muestras de color para teñirla - gris, amarillo, verde, azul, morado o rojo - para que un aviso se distinga de una tarea. Una nota se guarda en el grafo, así que las versiones, las restauraciones y las copias del workflow la conservan, pero nada la ejecuta ni la comprueba. Seleccionar una conexión ofrece un + que pone el siguiente paso elegido en su mitad, conectado por ambos lados donde los puertos encajan. Tidy up en la barra de herramientas alinea los pasos visibles de izquierda a derecha como una sola edición que se puede deshacer, el botón del mapa muestra un minimapa, el botón de paleta cambia los pasos entre color y Simple (véase Cómo se dibuja un paso), y el botón del teclado - o ? - enumera todos los atajos; Tab abre el selector de pasos. Ninguno actúa mientras escribes en un campo.

Cómo se dibuja un paso

Una tarjeta dice de qué tipo es el paso antes de decir qué hace. Encima del nombre, una etiqueta pequeña dice Family · Kind - AI · Classify, Data · Save a record - y el icono se asienta en una ficha dibujada en la familia del paso, las mismas secciones que usa el selector de pasos:

Familia	Su ficha
Start	Del color de la tinta - oscura en el tema claro, clara en el oscuro - y redonda, en una tarjeta con el extremo izquierdo redondeado
AI	Violeta sólido
Flow	Gris
Data	Verde azulado (teal)
Apps	Blanca con contorno azul, para que la marca de un servicio se asiente sin cambios
Error	Roja

Las familias se distinguen por luminosidad y forma además de por color, así que siguen distinguiéndose para quien no ve bien los colores y en un lienzo alejado hasta no poder leerse. El minimapa también dibuja cada paso con el color de su familia. El borde y el anillo de una tarjeta nunca son de una familia: pertenecen a la ejecución (véase más abajo), a un cambio, a una selección o a un paso desactivado.

La línea bajo el nombre empieza por aquello con lo que trabaja el paso - el agente, el modelo, la tabla - y sigue con lo que está configurado para hacer, como en gpt-4.1-mini · 3 categories.

Un paso que puede detener la ejecución lleva una banda en la parte superior de su tarjeta, redactada a partir de su configuración y nunca de una ejecución:

Paso	La banda dice
Approval	Waits for a person
Wait	Waits 2 days (or hours, minutes, seconds), Waits until a time o Waits a set time cuando un paso anterior aporta la hora o la duración, o Waits for a call - que gana si hay a la vez una duración y una llamada
Run a workflow	Waits for the called workflow; sin banda si Wait for it to finish está desactivado
MCP call	Asks before writes o Asks before every call, según su ajuste de aprobación; sin banda si nunca pregunta

Un paso que pregunta a una persona muestra la banda en rosa; un temporizador o una llamada, en gris. El paso de agente no tiene ninguna: sus aprobaciones vienen de la spec del propio agente, que la tarjeta no puede ver.

En el lienzo de una ejecución, un paso que espera a una persona se dibuja en rosa, con un reloj de arena en su etiqueta, se dibujen como se dibujen los pasos.

Simple dibuja todas las fichas neutras y el minimapa en gris, como se veía el lienzo antes de que los pasos tuvieran familias. Conserva lo que no depende del color: la etiqueta en gris, el extremo redondeado del inicio y una banda neutra. Se cambia con el botón de paleta de la barra de herramientas del lienzo o en Settings → Profile → Appearance → Workflow steps; se recuerda por navegador, como el tema.

Arrastra el borde derecho, el borde inferior o la esquina inferior derecha de un paso seleccionado para cambiar su tamaño. Una tarjeta mide de 200 a 560 px de ancho y hasta 400 px de alto, y nunca es más baja de lo que necesita su contenido. Más ancho da cabida a más del nombre y del resumen; más alto deja que el nombre se divida hasta en tres líneas y después el resumen en dos, y los puertos se quedan en la parte inferior de la tarjeta.

El tamaño se guarda con el borrador, así que deshacer, copiar, pegar, duplicar, las versiones publicadas y la exportación lo conservan. Reset size en el menú contextual del paso lo devuelve al tamaño predeterminado, y Tidy up coloca los pasos alrededor de los tamaños que tienen. Una versión publicada, una ejecución y una comparación muestran el tamaño guardado sin controles.

Configurar un nodo

Qué hace cada nodo, con qué se configura y qué significan sus fallos está en la referencia de nodos.

Un clic selecciona un paso y un doble clic lo abre sobre el lienzo. En una versión publicada o View only basta un clic. La cabecera muestra el nombre y un resumen desplegable de la configuración pendiente. Ábrelo para ver qué falta; elegir un campo lleva a su entrada. Después de intentar probar o publicar, los detalles de validación se abren automáticamente.

Connect account en un paso o en el selector de apps abre la configuración de cuentas existente sobre el workflow. Conecta una cuenta de organización, termina la configuración y selecciónala en el paso. El selector de secretos ofrece Add API key o New secret, selecciona automáticamente el secreto guardado y conserva solo su id en el draft. Un trigger sin credenciales de app OAuth ofrece Add credentials en el mismo lugar; el mismo formulario del almacén las guarda para la organización.

Parameters es aquello con lo que trabaja el paso y lo que debe hacer, en una sola lista, con la lista sobre la que trabaja primero: los Items de Filter antes de su Condition. Settings es cómo se ejecuta. Cada cambio se guarda en el draft al hacerlo, así que Done solo cierra el diálogo, y Delete step elimina el paso. Un diálogo de solo lectura muestra cada ajuste, desactivado, con su valor.

Un parámetro que toma texto es una sola caja para texto escrito y valores de pasos anteriores a la vez, como New lead: {{Form.payload.name}} from {{Form.payload.company}}. Data, a su lado, inserta un valor en el cursor, y lo mismo hace un campo arrastrado desde Input. Escribir {{ lista esos mismos valores y, dentro del payload de un trigger o del elemento de un bucle, los campos que vio allí la última ejecución de prueba; lo que escribes a continuación acota la lista, y Enter o Tab escribe el marcador.

Un marcador nombra un paso y una ruta en su salida, se colorea en la caja - en rojo, al salir de ella, cuando no nombra nada que este paso pueda leer -, se comprueba al publicar como cualquier valor leído de un paso y sigue al paso cuando se renombra. Con los datos de una ejecución de prueba, el resultado se previsualiza debajo.

No se evalúa nada: cuando el paso se ejecuta, cada marcador se convierte en el texto de su valor, en JSON para una lista o un objeto, y uno sin nada detrás hace fallar el paso con INVALID_BINDING, nombrándolo.

Cualquier otro parámetro - un número, una elección, un interruptor, una lista escrita como JSON - tiene su propio control, y Data, a su lado, toma el valor de un paso anterior en su lugar. Data muestra solo los valores alcanzables aquí con un tipo compatible, agrupados por paso, cada uno con el tipo de valor que contiene, y dice No compatible upstream outputs cuando no hay ninguno. El parámetro muestra entonces lo que lee - Run an agent › text - y × vuelve a un valor escrito.

Un parámetro obligatorio sin valor aún es un problema de validación, señalado en el paso en lugar de rellenarse en silencio con un valor predeterminado. Algunos parámetros contienen valores estructurados: una lista de filas a la que haces Add row, que reordenas y eliminas, o una elección tipada que cambia el subformulario de debajo. El diálogo entra en ellos en lugar de mandarte a otra pantalla.

Condiciones

Filter a list, If y Switch deciden con una condición hecha de filas: un campo del elemento o del valor, una comprobación - is equal to, is at least, contains, is not empty y las demás - y aquello con lo que se compara. Un número, true y false se comparan como tales, todo lo demás como texto. Con varias filas, Match all of these o any dice cómo se combinan, y se sugieren los campos que mostraron la última ejecución o los datos de prueba. La condición se guarda como la expresión JMESPath que evalúa el paso. Write it as an expression la edita como tal, y una que las filas no pueden mostrar sigue siendo una expresión.

Renombrar una regla de Switch, una categoría del clasificador, una rama de error, una rama de Split o una opción de aprobación traslada las conexiones, los enlaces y el quick log que usaban el nombre anterior, salvo que se reordenen, inserten o borren entradas, o cambien dos nombres a la vez.

Nombrar un paso, anotarlo y apagarlo

Hacer clic en el nombre del paso arriba en su diálogo le da un nombre propio, que se ve en su tarjeta y donde un paso posterior elige qué leer - dos pasos Send a message pasan a ser Tell sales y Tell support. Dos pasos no pueden compartir nombre, sin distinguir mayúsculas.

En Settings, Note guarda una línea para quien edite el workflow después, marcada en la tarjeta, y la pestaña lleva un punto en cuanto algo allí cambia.

Apagar allí Run this step, o Switch off en su menú contextual, deja el paso en el lienzo, atenuado, y lo salta cuando una ejecución llega a él: no hace nada y entrega lo que le llegó. Publicar rechaza un trigger o un paso que decide el camino apagados, y un paso que lee uno apagado, salvo que lo que le llega - por su única conexión de entrada, desde un paso encendido - tenga el campo leído, que entonces entrega. Los tres se guardan en el grafo, así que las versiones los conservan.

Los datos de un paso, datos de prueba y probar un paso

Al editar, el diálogo pone los parámetros de un paso entre dos paneles. Input muestra lo que entregó un paso anterior, el más cercano primero; cuando hay más, su encabezado permite elegir cualquier paso del que este pueda leer. Output muestra lo que entregó el propio paso, ambos de la última ejecución de prueba iniciada en el editor, o de la más reciente al abrirlo. Table dispone los datos en filas, una lista de registros con una fila por registro. JSON los muestra tal cual, y Fields lista cada campo por su ruta con una palabra sencilla para lo que contiene - text, number, list, ID: las rutas que lee un paso posterior.

Antes de cualquier ejecución, ambos paneles listan igual los campos que entrega un paso, y también se pueden arrastrar; un paso al que nada lleva dice Not connected yet. Una tabla muestra sus primeras 50 filas hasta que Show more despliega el resto, y una celda recortada a su columna muestra el valor entero al pasar el ratón.

Una columna o un campo de Input se puede arrastrar sobre un parámetro, que entonces lo lee de ese paso, como si se hubiera elegido en Data - en un texto, como marcador. Un campo que no encaja se rechaza con el motivo: un tipo que el parámetro no acepta, o un paso que no siempre se ejecuta antes que este.

Dentro de un valor sin forma declarada, como los values de un mapeo o el payload de un trigger, el tipo es el que mostró la ejecución. Data ofrece esos valores a cualquier parámetro, con Field inside it para la ruta. Mantener un campo arrastrado cerca del borde superior o inferior del formulario lo desplaza, para poder alcanzar un parámetro fuera de la vista.

Keep as test data conserva la salida en el paso, y Set test data escribe una como objeto JSON de 64.000 bytes como máximo. Una ejecución de prueba entrega los datos de prueba en lugar de ejecutar el paso, así que una llamada lenta a un modelo o una escritura en un sistema real se hace una vez y se reutiliza. Un paso que decide el camino nunca guarda datos de prueba, y publicar los quita todos: una versión publicada siempre ejecuta sus pasos. Un icono de chincheta marca la tarjeta, y Remove test data los quita.

Test step ejecuta el paso solo, y es el botón principal del panel mientras aún no hay datos. La ejecución conserva solo el paso y los pasos que llevan a él, y cada uno con salida conocida, de datos de prueba o de la última ejecución de prueba, la entrega en lugar de ejecutarse. El resto se ejecuta, y nada después del paso. Un paso que escribe pregunta primero, porque la prueba escribe de verdad. Un paso dentro de un bucle no se puede probar solo, porque se ejecuta una vez por elemento, así que prueba el bucle.

Mientras la prueba se ejecuta, el cuadrado junto a Test step la detiene. Cuando termina sin ejecutar el paso - detenida, enviada por otra rama o terminada antes de llegar a él -, una señal de advertencia ahí indica el motivo. Por la API, step en POST /api/v1/workflow-runs hace lo mismo.

Selectores de recursos

Un ajuste que fija un recurso abre un selector en vez de un campo de texto libre, para que un paso nombre algo real que tu organización tiene:

Selector	Qué fija
Agent y Version	Un agent, por su avatar y su descripción, y luego una de sus versiones publicadas, con la versión live marcada y la fecha y la nota de cada una. Cambiar el agent borra la versión fijada, porque una versión pertenece a un agent. La tarjeta del paso muestra entonces el avatar del agent y «nombre · v3»
Table y Columns	Una Virtual Table, y luego las columnas que el paso lee — acotadas al esquema actual de esa tabla
Secret	Un secreto del vault, por referencia. Un paso guarda la id del secreto, nunca su valor
MCP server y Tool	Uno de los servidores MCP de la organización, con la marca de su servicio, y luego una de las herramientas que listó en su última prueba. Elegirlo requiere poder editar el workflow - por rol o por un acceso concedido, como al publicar el paso -, no mcp:manage; solo quien gestiona servidores puede probar uno o añadir otro

Cada selector desambigua filas con el mismo nombre mediante contexto y marca una referencia cuyo destino ha desaparecido. Los selectores Agent y Secret ofrecen además un enlace para crear uno nuevo — siempre, no solo cuando la lista está vacía — mientras que el selector Table no tiene ninguno. Una tabla cuyo esquema cambió desde que se vinculó lo dice y ofrece Rebind to the current schema, para que un conjunto de columnas obsoleto sea un aviso visible y no una ruptura silenciosa.

Evals de un paso con modelo

Un paso que responde un modelo - un agente, Ask a model, Classify, Extract data, Summarize or translate o una decisión - tiene una pestaña Evals: los casos que debe resolver y lo que su respuesta debe decir entonces. Add a case toma la entrada con la que se probó el paso por última vez - la entrada de la ejecución y lo que entregaron los pasos anteriores -, así que prueba el paso una vez primero.

Luego nombra el caso e indica dónde mirar en la respuesta (text, category, una ruta como structured.amount o nada para toda la salida) y si debe contener, no contener o ser igual a un valor, sin distinguir mayúsculas ni los espacios alrededor.

Try inicia una ejecución de prueba del paso para cada caso, comprobada y facturada como cualquier otra, y cada caso se marca como superado o no cuando termina su ejecución, con lo que dijo la respuesta o por qué no la dio. Un caso cuya ejecución no puede iniciarse - demasiado trabajo en curso, el presupuesto mensual agotado - se marca como no superado con el motivo. Prueba los casos tras cambiar el prompt, el modelo o las instrucciones. Un paso admite hasta 50 casos, y probarlos requiere workflows:edit, como probar el borrador.

Agentes del catálogo

Run an agent selecciona un agente publicado del catálogo y fija su versión publicada actual. Puede elegir una versión anterior; los workflows publicados mantienen esa versión inmutable. Use published version completa una versión ausente antes de probar. Cree y edite agentes en Agent Builder.

Los grafos antiguos con un agente configurado dentro de un paso siguen ejecutándose. El editor conserva esa configuración hasta que se sustituya deliberadamente por un agente del catálogo. Ya no se crean agentes dentro de workflows. Max cost (USD) sigue limitando cada ejecución junto con los demás presupuestos.

Cuando un paso es lento o falla

En los Settings de un paso, When it is slow or fails fija su política. Handle errors da al paso un puerto Error: un fallo que sus reintentos no resolvieron sale por él, hacia un paso Handle error o lo que conectes, en lugar de hacer fallar el run. Tries es cuántas veces se intenta el paso en total, y Wait between tries y First wait fijan la pausa entre intentos. Un paso cuya llamada no es seguro repetir, como ejecutar un agent, lo dice y nunca se reintenta. Time limit corta una llamada tras esos segundos. Qué hace cada ajuste durante el run está en la referencia de nodos.

Un binding a un valor sin forma declarada - el elemento actual de un bucle, el payload de un trigger - ofrece bajo la fuente un campo Field inside it, donde escribes la ruta dentro de ese valor, como record_id o fields.Email. El run comprueba esa ruta cuando el paso se despacha, porque solo el run sabe qué contiene el valor.

Quick log

Un quick log escribe una línea en el log del workflow cada vez que un paso termina en una ejecución, así que ves lo que hizo un workflow sin abrir cada ejecución. Es un ajuste del paso. Pasa el cursor sobre una tarjeta y elige + Log: una franja LOG se acopla fuera del lado derecho de la tarjeta, los handles de salida del paso pasan a su borde exterior y cada salida registrada tiene una barra. Quita el quick log para dejar de registrar ese paso.

El mensaje es una plantilla de 1 a 500 caracteres, por defecto {{step}} → {{outcome}}. Puede usar {{step}}, el nombre del paso, y {{outcome}}, la salida por la que salió el paso. También los campos de salida del paso por su ruta, como {{record.id}}, y {{error.code}} y {{error.message}} para un fallo. Una referencia que no se resuelve se muestra vacía, y un índice de lista también: las rutas solo atraviesan objetos.

Outputs elige qué resultados escriben una línea. Por defecto lo hace cada salida; marca menos para registrar solo esas, y quita el quick log para no registrar nada. Un quick log no se admite en un paso Loop item ni Loop yield. Ponlo en el propio paso For each: escribe una línea, por su salida done, cuando su bucle se cierra. Un paso sin salidas registra sus fallos.

Los fallos siempre se escriben. Un fallo que ningún puerto error encamina se registra sea cual sea la selección de salidas, porque una ejecución que falló en silencio es justo para lo que sirve un log. Un fallo encaminado por un puerto error sigue el filtro Outputs como cualquier otro resultado.

No se escribe ninguna línea para un paso omitido, desactivado o que nunca empezó, ni para uno que un reintento desde el paso fallido reutilizó en vez de ejecutar. Un log nunca cambia una ejecución: un mensaje que no se puede escribir se descarta y la ejecución sigue como habría seguido. Una ejecución de prueba también escribe líneas, marcadas como de prueba, y la línea de un paso que entregó datos de prueba fijados se marca como fijada.

Las líneas se conservan con su ejecución y se eliminan con ella cuando la retención del historial elimina la ejecución (consulta Ajustes del workflow). Las lees en la página Logs o, por paso, en la vista de la ejecución.

Conexiones y scope de foreach

Dibujas una arista conectando el puerto de salida de un nodo con el puerto de entrada de otro nodo. El editor rechaza una conexión entre puertos que llevan formas distintas antes de dibujarla, así que un cable incompatible nunca aterriza en el lienzo, y dibujar una conexión que ya existe no hace nada.

Una arista fija el orden en que se ejecutan los pasos; no mueve ningún dato. Los valores que lee un paso son sus bindings, descritos en Configurar un nodo.

Para que un cable no te deje enlazando cada campo a mano, conectar dos puertos que llevan exactamente la misma forma — la salida de un Echo con la entrada de un Relay, por ejemplo — también enlaza cada input del destino con el campo del mismo nombre de la fuente. Un campo que ya habías enlazado se deja como está.

Cuando las formas difieren, o un puerto no lleva datos, una elección se hace igualmente por ti: un paso que trabaja sobre una lista, conectado tras un paso que entrega exactamente una - Filter a list tras List records -, lee esa lista. No se enlaza nada más, y eliges cada fuente tú mismo con Data. Undo (Ctrl/Cmd + Z) deshace la conexión junto con sus bindings, y borrar una arista más tarde deja sus bindings donde estaban, así que quítalos o vuelve a enlazarlos en los ajustes del paso.

Para borrar una conexión, selecciónala: haz clic en el cable y se dibuja más grueso y aparece sobre él un botón Delete connection. Pulsa el botón, o Delete o Backspace, y la conexión desaparece, mientras los dos pasos se quedan. Las conexiones de una versión publicada no se pueden seleccionar, así que no se pueden borrar.

Un paso For each ejecuta su cuerpo una vez por cada elemento de una lista. El cuerpo no es un documento aparte - es parte del mismo grafo plano, mostrado por su cuenta. Edit loop body en el paso, que dice cuántos pasos contiene el cuerpo, entra en esa vista, y las migas Workflow scope en la esquina del lienzo muestran dónde estás, desde Workflow hasta el bucle que abriste. Cada miga vuelve hacia fuera.

Un cuerpo empieza en Loop item, al que se conecta el puerto Each item del bucle, y termina en Loop result; nada en él vuelve al bucle, que continúa por Done cuando cada elemento ha pasado por el cuerpo. El selector de pasos y las fuentes de binding siguen el scope en el que estás, y un paso del cuerpo puede leer cualquier cosa que se ejecutara antes del bucle. Qué hace el bucle está en la referencia de nodos.

Ramas paralelas

Cualquier paso puede enviar un puerto de salida a varios pasos, y estos se ejecutan al mismo tiempo. El paso Split hace lo mismo con ramas con nombre y las toma todas; no tiene condición y no puede encaminar errores. Cuál de las ramas termina primero no está definido, así que nada debe depender del orden. Dibuja las patas y únelas donde un paso posterior necesite lo que hicieron.

Un paso con varias conexiones de entrada es un join y no necesita Merge. Se ejecuta cuando cada paso que lleva a él ha terminado, si al menos una de sus conexiones está activa: una pata que un If no tomó no lo retiene. Se omite si ninguna conexión está activa y si un paso que lleva a él falló sin camino de error. Sus bindings solo pueden leer pasos que seguro se ejecutaron antes, así que un join puede leer cada pata de un grupo paralelo, pero no la rama de un If, que quizá no se ejecutó.

Un Merge tiene el ajuste Wait for. The branch that ran pasa la salida de la única rama que llegó a él, y publicar lo rechaza cuando dos de sus entradas pueden ejecutarse juntas. All branches espera a cada entrada y pasa cada una por nombre como branches, de modo que los pasos posteriores leen branches.<nombre>; cada conexión tiene un Branch name.

Publicar lo rechaza cuando una entrada puede no ejecutarse - nombrándola - o cuando solo una puede ejecutarse. Conectar una segunda pata a un merge elige el ajuste que el grafo necesita, y renombrar una rama arrastra los pasos que la leen, en un solo deshacer. Los detalles están en la referencia de nodos.

Publicar rechaza además un grafo con dos pasos Output, o dos pasos Respond to webhook, que puedan ejecutarse ambos en un mismo run, y un Error handler alimentado por dos pasos que pueden fallar en el mismo run. Da a cada pata el suyo.

Una rama que falla sin camino de error hace fallar el run. Los pasos que están a su lado no empiezan nada más, y lo que tenían en marcha se cierra: aprobaciones y temporizadores pendientes y los runs de agent en que un paso está aparcado. Un paso que termina después queda registrado como Finished after the run stopped, con su trabajo conservado, y un reintento lo reutiliza en lugar de hacerlo otra vez. El estado del run sigue a sus pasos activos, así que una rama que espera una aprobación se ve aunque otra siga ejecutándose.

El budget del run se comparte. Cada paso que gasta, y cada workflow que llama, toma de lo que el límite deja tras el gasto y tras lo que retienen otros pasos en curso, nunca más que su propio max_cost_usd. Un paso que encuentra el resto en manos de sus vecinos espera y vuelve a preguntar, cada vez algo más tarde, en lugar de recibir todo el resto. Una reserva termina cuando termina el paso que la tomó.

Los pasos de IA hermanos se ejecutan a la vez bajo el budget de un run solo si cada uno tiene su propio max_cost_usd: un paso sin él retiene todo el resto, así que sus vecinos esperan hasta que termine.

Cuántas ramas se ejecutan a la vez lo fija el worker, no el run. No hay límite por run, así que las ramas de un run pueden ocupar todos los slots de workflow de un worker, WORKER_WORKFLOW_CONCURRENCY (cinco por defecto, véase Configuración), y el resto espera en cola. Un run por el que alguien espera pasa delante de uno que se inició solo. Una bifurcación ancha en un run ralentiza por tanto otros runs de ese worker; que sea tan ancha como pida el trabajo.

Retroalimentación de validación

El editor comprueba el grafo mientras editas. Antes de probar, los pasos incompletos llevan un indicador neutro y el lienzo muestra Finish setup. Abre la lista para saltar a un paso. Probar o publicar revela los errores; salir de un campo obligatorio vacío muestra su mensaje inline. La publicación sigue bloqueada hasta resolver todos los problemas de validación.

Los ajustes de un paso se mantienen cortos. Lo que el paso necesita, y lo que ya estableciste, se ve de inmediato; los ajustes opcionales aún en sus valores predeterminados esperan tras un botón que los cuenta - 3 more options -, que los despliega encima de sí mismo hasta Fewer options, y cómo se ejecuta el paso espera bajo Settings.

Un valor obligatorio que aún no has dado no se señala junto a su campo hasta que dejas ese campo o intentas ejecutar o publicar: la marca del paso en el lienzo lo dice desde el principio. Una descripción que solo repite el nombre del campo es una pista sobre el nombre en lugar de una línea bajo el campo.

Los mensajes nombran el fallo concreto: un input obligatorio sin valor, un input puesto por más de una fuente, una conexión cuyos puertos llevan formas distintas, un paso que no se puede alcanzar desde el inicio, un bucle de vuelta a un paso anterior, un valor que lee un paso que no se ha ejecutado en todos los caminos que llegan aquí, o una conexión que cruza hacia dentro o hacia fuera del cuerpo de un bucle.

La comprobación del editor es una vista previa; la publicación es la autoridad

La validación en el editor es un espejo rápido de las reglas que el servidor impone. Existe para atrapar un problema mientras lo estás mirando, pero nunca es la última palabra: publicar vuelve a ejecutar la validación completa en el servidor, y un problema que el editor pasó por alto se muestra de la misma manera, contra el nodo o el campo al que pertenece.

Autoguardado y el banner de conflicto de revisión

Tu draft se guarda solo. Una breve pausa después de que dejas de editar escribe el grafo actual, y el estado bajo el título, tras sus etiquetas, lo refleja — Unsaved changes mientras un guardado está pendiente, Saving… mientras se ejecuta, Saved una vez que aterriza, y Save failed — will retry si no lo hizo.

Cada guardado se escribe contra la revisión que abriste, así que un draft editado en dos sitios a la vez no puede sobrescribir en silencio. Cuando eso ocurre, el editor levanta un banner titulado This draft changed elsewhere: Someone edited this workflow since you opened it. Overwrite keeps your changes; reload replaces them with the latest saved draft. Eliges:

• Overwrite — conserva tu versión y escríbela sobre la guardada en otro sitio.
• Reload — descarta tus ediciones sin guardar y toma el último draft guardado.

Publicar una versión y el historial de versiones

Configurar la autoridad de ejecución desatendida requiere una sesión de miembro: publicar un disparador de webhook, programación, tabla, formulario, GitHub, correo o canal, activar su exposición, rotar su secreto o enlace de formulario, cambiar su programación y elegir un workflow de errores. Las claves API de organización pueden publicar workflows manuales, iniciar ejecuciones permitidas y pausar automatizaciones; no pueden conservar la autoridad del usuario que emitió la clave para eventos futuros. En instalaciones preliminares, vuelve a publicar la automatización existente desde una sesión de miembro de confianza; los registros históricos no conservan la procedencia de la clave de publicación.

Los pasos MCP comprueban la visibilidad actual de la conexión, el acceso por grupos y permisos sobre el recurso y allowed_tools al publicar y ejecutar. Una lista vacía no permite herramientas. Retirar el acceso después de publicar bloquea la ejecución antes de leer credenciales o contactar con el servidor.

La extracción DOCX procesa el XML del documento como flujo y se detiene en el límite de caracteres configurado, con descompresión y anidamiento limitados. El límite se aplica sin construir todo el árbol del documento.

El historial carga 50 entradas de metadatos cada vez; More solicita versiones anteriores. La API acepta before y limit (1–100), devolviendo next_before hasta agotar las versiones. Los grafos se cargan al abrir una versión. Una página fallida puede reintentarse sin perder las entradas ya cargadas.

Publish congela el draft actual como una versión inmutable que se ejecuta — una versión nunca se cambia después de crearse. El diálogo de publicación nombra la versión que crea y toma una Release note opcional que describe qué cambió; si el draft no cambió desde la versión en vivo, lo dice primero. Si el grafo aún tiene problemas, la publicación se bloquea con Fix the problems below before publishing, así que una versión que no validaría nunca se crea.

Publicar no termina tu edición. El draft sigue existiendo con independencia de cualquier versión publicada, así que lo sigues editando enseguida. Versions en la cabecera del editor abre cada versión publicada con su release note, la que está en vivo marcada Live. View abre una versión anterior en solo lectura - una versión publicada es de solo lectura, y para hacer cambios sigues editando el draft.

Para volver a una versión publicada, ábrela con View y elige Restore to draft. Tras confirmarlo, el draft toma el grafo de esa versión, y lo que no estaba publicado en el draft se descarta. La versión en sí no cambia, y no se publica nada hasta que vuelvas a publicar el draft. Deshacer empieza de nuevo desde el grafo restaurado. Si alguien cambió el draft desde que lo abriste, la restauración se rechaza con el mismo banner de conflicto que muestra un guardado, en vez de descartar su cambio. Restaurar requiere workflows:edit sobre el workflow, y un workflow archivado no se puede restaurar. Cada restauración queda en el registro de auditoría como workflow.version_restored.

Compare with draft en la vista previa de una versión dibuja la versión y el borrador en un mismo lienzo: cada paso que el borrador añadió, cambió o quitó queda marcado en su tarjeta, y la lista al lado nombra cada paso cambiado con lo que cambió en él - un ajuste, una entrada, su nombre, nota o versión, si está apagado y qué hace cuando va lento o falla. Mover un paso y los datos de prueba fijados no son cambios. Show this version vuelve a la versión sola.

Ajustes del workflow

Settings agrupa tiempos y errores, historial y retención, y límites en secciones desplegables. Las secciones con valores modificados empiezan abiertas. La página de ejecuciones comienza por el historial; Live performance despliega estadísticas de ejecuciones publicadas. Runs y Logs reúnen los controles secundarios en Filters. Un filtro de ejecución rechazado desde un enlace abre automáticamente su campo y su error.

Los resultados inline retenidos comparten límites: WORKFLOW_RUN_MAX_INLINE_RESULT_BYTES (64 MiB por ejecución) y WORKFLOW_ORG_MAX_INLINE_RESULT_BYTES (1 GiB entre ejecuciones retenidas). Las reservas cuentan resultados compactos, incluidas salidas sintéticas de bucles y posibles copias de resultado, webhook y error. No miden el almacenamiento físico de PostgreSQL ni sustituyen la política global del despliegue. Pequeños registros terminales pueden superar una cuota llena para cerrar la ejecución. WORKFLOW_INLINE_RESULT_LIMIT no admite desvíos por rutas de error; conserva costes y no repite efectos automáticamente. El handler puede haber actuado antes del rechazo. Usa referencias de archivos o retención del historial para liberar reservas.

Un agente reanudado conserva el límite más estricto: su techo guardado al pausarse o lo gastado más el presupuesto actual restante del workflow. El gasto de ramas paralelas durante una aprobación no restaura el margen anterior. Cada caso eval consume una unidad de ejecución, también dentro de un lote; los casos sin cuota se registran como rechazados. La primera reserva HTTP se acredita al primer caso.

Las salidas fijadas importan referencias anidadas de archivos después de comprobar el acceso actual. La admisión y la retención comparten el bloqueo de archivos: una importación confirmada protege al productor y la limpieza vuelve a comprobar las referencias tras esperar. Los ejemplos del editor conservan los datos más recientes aunque lleguen respuestas antiguas; pegar conserva notas y los cambios mixtos de notas y pasos se aplican juntos.

La migración 0231_workflow_result_bytes.py rellena contadores desde JSON existente sin comprimir, de forma conservadora frente a las nuevas reservas compactas. Detén las escrituras de API y workers durante este proceso. Los historiales que exceden la cuota se conservan, pero bloquean nuevos resultados grandes hasta limpiar o aumentar el límite. No se recupera contenido ya eliminado.

Las reservas incluyen la entrada inicial, el snapshot del borrador en modo test y cada payload de reanudación Wait almacenado. Admission y resume reservan antes de escribir o despertar pasos; el rechazo devuelve WORKFLOW_INLINE_STORAGE_LIMIT (429). Los enlaces resume autentican antes de leer el cuerpo. La migración 0232_workflow_input_bytes.py añade los payloads existentes a los contadores sin eliminar resultados ni costes. Detén API y workers durante el backfill; una organización que ya supera el límite debe limpiar historial o ampliar el límite.

Borradores, versiones publicadas e importaciones retenidas protegen sus archivos de la retención. No se puede eliminar un workflow productor mientras otro referencia sus archivos; elimina las referencias o archívalo. Edición, admission, importación y limpieza comparten el bloqueo de ciclo de vida de la organización. La eliminación comprueba dependencias entre runs antes de quitar triggers e intenta desregistrar los hooks GitHub mediante la integración de cuenta; los fallos del proveedor quedan en logs.

Combine by key acepta claves escalares y rechaza listas u objetos sin reintentos. La creación de eval cases serializa el límite y la asignación de posición. El dashboard incluye todos los workflows visibles, incluso más de 500, y un run terminal actualiza archivos independientemente de cuándo llegaron sus pasos.

Las importaciones anidadas se deduplican por ID y se limitan mediante WORKFLOW_GRAPH_MAX_BINDINGS antes de validar en la base de datos.

El run de origen se conserva mientras haya un reintento activo u otro run retenido importe uno de sus archivos. Terminar un reintento no invalida archivos que sus pasos aún referencian.

Settings, en More en la cabecera del editor, guarda con qué se ejecuta un workflow, no lo que hace. Los ajustes son del workflow, no de una versión: un cambio vale para cada ejecución iniciada después, y publicar los conserva.

• Timezone - en ella se lee la expresión cron de una programación, también con el cambio de hora, y en ella escribe un paso Date & time que no indica zona propia. Una ejecución conserva la fijada al empezar. UTC si no se indica. El campo dice qué hora es allí ahora y rechaza una zona que el navegador no conoce.
• Default deadline - el plazo que recibe una ejecución cuando lo que la inicia no indica ninguno.
• Error workflow - un workflow publicado que empieza por On failure of a workflow, iniciado una vez cuando una ejecución falla. Consulta Cuando otro workflow falla.
• Keep runs for y Keep runs that succeeded - un barrido diario elimina una ejecución y los archivos que guardó tantos días después de que termine, y una ejecución con éxito al día siguiente cuando no se conservan las exitosas. Sin indicarlo, las ejecuciones se conservan siempre.

Limits acotan lo que sus ejecuciones hacen a la vez y gastan, por encima de los límites propios de cada paso - el techo de coste de un paso de agente entre ellos:

• Runs under way at once - una ejecución real iniciada por encima se rechaza con 429 hasta que termine una. Al remitente de un webhook o de GitHub se le pide que reintente, una programación espera a su siguiente tic, y un evento de tabla o una respuesta de formulario por encima se rechaza. Un buzón se vuelve a leer un minuto después, sea cual sea su intervalo, así que el mensaje espera a que termine una ejecución - salvo que las que ocupan el límite esperen una aprobación: entonces el mensaje se omite para este workflow y el registro de auditoría lo anota (workflow.mail_message_skipped). Las ejecuciones de prueba ni se cuentan ni se retienen.
• Most one run may spend - el presupuesto propio de la ejecución, el más estricto entre él y el de la versión: una ejecución que lo alcanza se detiene antes de su siguiente paso, sin presupuesto.
• Most its runs may spend a month - contado sobre el mes natural en UTC, ejecuciones de prueba incluidas. Una vez alcanzado, no se inicia ninguna ejecución - 402 - hasta que cambie el mes o se suba el presupuesto. La página de ejecuciones muestra el gasto del mes frente a él.

Por la API, PUT /api/v1/workflows/{id}/settings los reemplaza.

La retención elimina el contenido y los archivos de las ejecuciones, pero conserva los importes y las fechas de admisión para el cálculo del presupuesto mensual. Eliminar el historial no repone el presupuesto mensual del workflow. Los costes eliminados antes de introducir este registro no se pueden reconstruir.

Ejecutar un workflow

Test draft, en la cabecera del editor, ejecuta el draft al momento, nunca la versión publicada - Ctrl/Cmd + Enter también -, pidiendo antes los campos que declara un trigger Manual o API. El run aparece luego en el lienzo mientras ocurre.

Una píldora en la esquina de cada paso dice en qué punto está - Pending, Starting, Running con un contador de tiempo en marcha, Waiting, Failed, Needs attention, Skipped o Not reached -, y un paso que salió bien muestra cuánto tardó. El cable que entra en un paso en ejecución se mueve, el camino recorrido se vuelve verde y una rama que el run no tomó se atenúa. Un paso fallido muestra su error bajo su tarjeta y se sacude una vez.

Una conexión dice cuántos elementos pasaron por ella cuando el paso anterior entregó una lista, y una barra abajo dice cómo va el run, con Open run para su página. Mientras el run sigue, el cuadrado junto a Test draft lo detiene, sin preguntar nada. El lienzo conserva el run cuando termina; la siguiente edición lo oculta y deja una barra que dice que el grafo cambió desde entonces, aún con Open run. Un paso que esperó y siguió cuenta un intento, no dos. Test draft espera mientras un cambio se sigue guardando, y dice por qué no puede ejecutarse mientras el draft tenga problemas.

Runs en la cabecera del editor, y el icono de runs en la tarjeta de un workflow, abren sus runs, del más reciente al más antiguo, cada uno con su estado, si ejecutó el draft o la versión publicada, qué lo inició, cuándo, cuánto duró y cuánto costó. Start a run inicia uno a mano: Test the draft ejecuta el draft tal como está, y Published version ejecuta la versión en vivo. Su Input (JSON) es lo que el paso Input del workflow entrega como payload.

Sobre la lista, How it ran resume las ejecuciones reales de los últimos 7, 30 o 90 días: cuántas se ejecutaron y cuántas fallaron, la parte de las terminadas que salió bien, el tiempo típico y el tiempo en el que terminan 95 de cada 100, y lo que costaron por día. La tarjeta de coste da también el gasto de este mes, ejecuciones de prueba incluidas, frente al presupuesto mensual del workflow - en rojo cuando se agota. By step muestra de dónde vinieron el tiempo, el coste y los fallos, primero lo más caro. Por la API es GET /api/v1/workflows/{id}/stats?days=30.

Si el workflow pidió aprobación a una persona en ese periodo, Approvals resume cómo se decidió: Approved as proposed, Edited before approval con la mediana de la parte del texto que cambiaron las ediciones, Rejected, cuántas solicitudes caducaron y el Time to decide, el típico y aquel en el que se decide 95 de cada 100. Una tabla da las mismas cifras para cada paso de aprobación.

La ventana son los mismos días, contados desde que se preguntó a la persona, y las ejecuciones de prueba se dejan fuera. La proporción aprobada y la proporción aprobada como se propuso (acceptance_rate y unchanged_rate en la API; la tarjeta muestra la segunda) se calculan sobre las solicitudes decididas, aprobadas o rechazadas: una solicitud que caducó o se canceló con su run nunca se decidió, así que se cuenta pero no entra en las tasas. Un paso que no se puede editar cuenta como aprobado como se propuso. Las cifras dicen lo que pasó y no lo juzgan.

Las cifras son por paso y por día, no por tipo de mensaje. Para comparar categorías, dirige cada una a su propio paso de aprobación.

Cuánto cambió una edición se mide una vez, cuando la persona decide, con el mismo medidor que text.compare, por caracteres: 0 cuando aprobó la propuesta tal cual en un paso que se puede editar, hasta 1 cuando no queda nada de ella. Un paso que no se puede editar, un rechazo y una caducidad no tienen esa cifra. Una edición decidida antes de que se midieran las aprobaciones tampoco la tiene y queda fuera de la mediana, en vez de contar como sin cambios; cuando no se midió ninguna edición del periodo, la tarjeta dice Change not measured.

Las mismas cifras llegan por la API en el bloque approvals de las estadísticas. Sobre todos los workflows que ves, en las fechas que elijas, GET /api/v1/workflow-approvals/stats?from=2026-10-01&to=2026-10-31 da los totales y los cinco workflows con más solicitudes, y los muestra la tarjeta Approval outcomes del dashboard.

La tarjeta Workflows del dashboard suma lo mismo para cada workflow que puedes ver, en el periodo al que está ajustado el dashboard: runs, fallos, coste y los cinco más activos. Encima cuenta los runs que esperan ahora a una persona - una aprobación o un paso que necesita atención -, empezaran cuando empezaran. Por la API es GET /api/v1/workflows/summary?from=2026-10-01&to=2026-10-31.

Un run se abre con su duración, su coste (un gasto por debajo de $0.0001 se muestra como <$0.0001, no como cero) y cuántos pasos dio, y luego con el error con el que terminó, si lo hubo. Junto a ellos está el grafo que ejecutó, dibujado como el editor dibuja un run: la píldora de cada paso, sus intentos y su error, y los pasos a los que nunca llegó atenuados. Solo se mueve una página abierta mientras el run seguía; una abierta después queda quieta. Open loop body muestra las iteraciones de un bucle de la misma manera.

La respuesta del run - su texto, su resultado estructurado, los pasajes en que se apoyó y cuántos archivos creó, con el JSON en sí bajo Raw output - y cada paso que dio, iteración a iteración, están al lado. Un run en curso se actualiza cada par de segundos, y Cancel run lo detiene y retira los temporizadores que sus pasos en espera habían puesto en cola. Sus Files listan lo que guardaron sus pasos - una descarga, una página renderizada, la salida de un script -, cada uno descargable.

Un run que espera un paso Ask for approval aparece en la pestaña Approvals de Activity. Cuando el paso tiene activado Let the approver edit y una propuesta vinculada, como una respuesta redactada, quien aprueba la cambia allí en un editor, con Restore original y Show changes, y aprueba su versión. El paso pasa entonces final, original y edited, de modo que un paso posterior envía lo que la persona aprobó. Quien puede decidir pero no está nombrado en el paso ve la propuesta de solo lectura, y una solicitud decidida con una versión cambiada lleva la insignia Edited en Decided.

Cuando el paso enumera Ways to approve, la cola muestra un botón por cada una, con la etiqueta que escribió su autor, en lugar de Approve; Reject se queda. Cada forma es un puerto de salida del paso, así que el workflow sigue por la que pulsó quien aprueba, y la fila decidida la nombra. Una edición va con el botón que se pulse.

En la lista, la versión de un run de prueba dice Draft (test) y la de uno real Published, y un run iniciado desde la consola o la API HTTP dice Console or API. Status, Version, Started by y Started (la última hora, día, semana o 30 días) acotan las ejecuciones, y la lista responde una página cada vez; cada filtro queda en la dirección, así que una lista filtrada se puede enlazar. Runs en la lista de workflows muestra juntas las ejecuciones de todos. En la página de una ejecución, hacer clic en un paso muestra su Input y su Output de esa ejecución.

Las líneas que escribió el quick log de un paso aparecen debajo del paso.

Retry from failed step inicia una ejecución nueva de la misma versión con la misma entrada, en la que cada paso que tuvo éxito entrega lo que entregó antes, así que solo se ejecutan el paso fallido y lo que no alcanzó, y una escritura nunca se hace dos veces. Un bucle vuelve a ejecutarse y reutiliza los pasos de cada elemento que tuvieron éxito. Debug in editor fija en los pasos del borrador lo que cada paso fuera de un bucle entregó en esa ejecución, así que una ejecución de prueba empieza donde estaba aquella. Por la API, POST /api/v1/workflow-runs/{id}/retry reintenta, y GET /api/v1/workflow-runs acepta status, mode, triggered_by, created_after y created_before.

Resolve aparece en un paso que necesita atención mientras su run sigue activo. Un paso necesita atención cuando pudo haber actuado y nadie vio su final, o cuando dejó de esperar y nada lo despertará. El diálogo nombra el paso y dice de qué caso se trata. Run it again pone el paso en cola para un nuevo intento en el mismo run, y en un paso que pudo haber escrito algo avisa de que así puede hacerse dos veces. Treat it as failed es Take its error route, donde el paso encamina sus errores o está en un bucle, o Fail the run. Si el paso informó de un resultado después de que se renunciara a él, Use that result continúa desde ese resultado. Nada más del run se toca, así que los pasos vecinos, las aprobaciones y los temporizadores siguen.

Solo puede resolver un paso quien inició el run o un editor del workflow, y en un run de prueba solo un editor puede resolver un paso o reintentar el run. Por la API se hace con POST /api/v1/workflow-runs/{id}/steps/{node_run_id}/rerun y un choice, y la decisión queda auditada. Un run cancelado o fallido no tiene paso que resolver: Retry from failed step inicia un run nuevo. Un paso que terminó después de que su run se detuviera se marca como Finished after the run stopped, y un reintento lo reutiliza.

La página Logs

Logs, en More en la cabecera del editor, lista lo que los quick logs del workflow escribieron en sus ejecuciones, las más recientes primero: cuándo, el paso, su resultado y el mensaje. Acota las líneas por Step, Outcome y Written (la última hora, día, semana o 30 días), busca en el mensaje y activa Include test runs: hasta entonces las ejecuciones de prueba quedan fuera. Para ver las líneas de una sola ejecución, pega su id en Run o escribe los primeros caracteres (al menos cuatro); Show only this run en una línea rellena el campo, y See in Logs en la página de una ejecución abre los logs filtrados por esa ejecución. Una línea abre la ejecución que la escribió. En la vista de la ejecución, las líneas de cada paso están debajo de él, en el orden en que se escribieron. Una clave de API de la organización con workflows:view también las lee, para las ejecuciones de origen público: consulta Leer el log de un workflow.

Alertas

Una alerta avisa a las personas cuando el log registra algo con demasiada frecuencia. Debajo de la lista, la tarjeta Alerts reúne las reglas de un workflow; Add alert abre una nueva. Una regla tiene un nombre y cuenta las líneas que coinciden:

• Outcomes: los resultados que cuentan, entre los que escribe el log del paso elegido, más error. Una línea que salió por varios puertos coincide con cada uno.
• Step: un paso, o cualquier paso que registre.
• Message contains: palabras opcionales, sin distinguir mayúsculas.
• Occurrences y Within: al menos esas líneas coincidentes (de 1 a 1000) en 5, 15, 30 o 60 minutos, 4 horas o un día.

Una regla se dispara como máximo una vez por ventana: tras dispararse, calla durante la duración de su ventana, luego vuelve a contar desde ese momento, y ninguna línea se cuenta para dos disparos. Solo cuentan las ejecuciones reales; las líneas de una ejecución de prueba nunca provocan una alerta. Un workflow tiene hasta 25 reglas, y un interruptor en cada una la pausa.

Who is told es el propietario del workflow, con el que empieza una regla nueva, los administradores de la organización o personas concretas que elijas; quien ha dejado la organización se omite. Cada una recibe una notificación en la campana y un correo, según sus propias preferencias de notificación, y quien ya no puede ver el workflow deja de verla. La notificación dice cuántas líneas coincidieron y su enlace abre la página Logs filtrada por el paso y los resultados de la regla. Una regla con un resultado que el paso de la versión publicada no tiene aparece marcada en la lista.

Las reglas las ve quien puede ver el workflow; las crea, cambia, pausa y borra quien puede editarlo, por rol o por un grant sobre él. Las reglas no forman parte de la API pública.

Iniciar un workflow desde fuera de la consola

Un workflow puede tener varios triggers independientes, como Manual, Webhook y Schedule. Añadir uno conserva los inicios y conexiones existentes. Cada run elige un inicio y ejecuta solo su rama alcanzable; no espera a otro trigger. Un paso compartido solo puede leer datos disponibles desde todos los inicios que llegan a él. Normaliza las entradas distintas por separado antes de compartir pasos.

Publicar activa todas las entradas desatendidas configuradas con los permisos del miembro que publica. Se admite como máximo un trigger de cada tipo desatendido por workflow. Volver a publicar conserva las direcciones y credenciales de los nodos retenidos y elimina los registros retirados. Trigger, en More, muestra todos los inicios publicados y sus controles. Active en la cabecera pausa o reanuda todos los registros. Test draft permite elegir el inicio; la API acepta entry_node_id, pero las peticiones reales solo pueden seleccionar Manual/API, nunca una entrada desatendida.

Una versión que empieza por Manual o API request, o sin ningún trigger, la inicia quien pueda ejecutarla, como sí mismo: Start a run en Runs, la API HTTP o un WebSocket. Cada run se comprueba, factura y audita como uno iniciado aquí. Esas vías no inician ningún otro trigger, y cada otro trigger tiene la suya. Un run de prueba del draft acepta cualquier trigger, y Start a run lo abre con una entrada con la forma de ese trigger.

Manual es el trigger que una persona inicia con Test draft; API request es el que llama un sistema, y Trigger muestra su endpoint y una petición de ejemplo. Dale a cualquiera de los dos campos de entrada y un run pide lo que necesita: Test draft y Start a run muestran un formulario con una casilla por campo en lugar del JSON, con el tipo del campo, y una llamada a la API cuya entrada no encaja se rechaza con los campos que están mal. Consulta core.input.

Desde el chat

El selector del chat de quién responde enumera, debajo de los agentes, los workflows publicados que empiezan por Chat message. Con uno elegido, cada mensaje inicia un run de él, y el trigger pasa a los pasos siguientes el mensaje como prompt, con el conversation_id y el user_id de quien lo envió. El hilo muestra una tarjeta con el estado del run y un enlace a sus pasos, y la respuesta del workflow la sigue cuando el run termina.

La respuesta se escribe en la conversación cuando el run termina, siga el chat abierto o no, así que al volver a abrir la conversación se lee de nuevo. Un run escribe en la conversación desde la que se inició y en ninguna otra parte: llegar a cualquier otra persona requiere un paso HTTP o de notificación en el grafo.

Open chat en la cabecera del editor prueba un borrador que empieza con un mensaje de chat sin salir de él. Cada mensaje enviado en el panel inicia un run de prueba del borrador con ese mensaje, el run se abre en el lienzo y su respuesta - el texto del paso Output - aparece bajo el mensaje. Son runs de prueba sin conversación a la que responder, así que nada del panel llega a un chat real. New chat empieza de nuevo con un id de conversación nuevo.

Por un WebSocket

/api/v1/ws/workflow-runs inicia un run y transmite sus eventos, o sigue uno que ya está en marcha. Un cliente que perdió la conexión se reconecta con el cursor del último evento que vio y retoma exactamente donde lo dejó. Los eventos se escriben antes de enviarse, así que nada se pierde y nada se ejecuta dos veces. El socket vuelve a comprobar la sesión y el acceso del miembro antes de cada frame y de cada lectura del flujo. Los frames están en La API HTTP.

Un webhook o una programación

Un trigger Webhook recibe su dirección y su signing secret la primera vez que se publica una versión que lo tiene. La publicación muestra el secreto una vez, y las publicaciones posteriores del mismo nodo conservan ambos; un nodo de webhook borrado y añadido de nuevo recibe una dirección nueva.

El remitente firma con el secreto el cuerpo exacto de la petición, HMAC-SHA256 en X-Signature-256, y nombra cada entrega en X-Delivery-Id; las cabeceras propias de GitHub también funcionan. El trigger pasa el JSON de la entrega como body, con su delivery_id. Un reintento que repite un id recibe como respuesta el primer run y no inicia nada, porque el id se guarda junto con el run que admitió, en una sola transacción.

Un trigger Schedule se ejecuta cada cierto tiempo, a diario a una hora fija o según una expresión cron, en la zona horaria del workflow (UTC salvo que sus Settings indiquen otra) y como mucho una vez por minuto, en su tic y no en el siguiente barrido después de él. Su Input es aquello con lo que empieza cada run, pasado como input junto al fired_at del tic. Un tic que encuentra el último run aún en marcha se omite en lugar de apilar un segundo run detrás, y un tic que la cuota de admisión rechaza espera al siguiente.

Los dos se ejecutan como el miembro que publicó la versión, y su acceso se comprueba de nuevo en cada disparo. Un webhook cuyo miembro ya no puede ejecutar el workflow rechaza sus entregas, y una programación así se desactiva y queda registrada en el registro de auditoría. Pause, en la hoja Trigger, detiene cualquiera de los dos sin publicar, y New secret sustituye el secreto de un webhook; el anterior deja de verificarse al instante.

El cuerpo de los webhooks se limita durante la transmisión, incluso sin Content-Length. Las entregas de prueba tienen el límite de datos fijados de 64 KB; las entregas normales y de GitHub usan WORKFLOW_RUN_MAX_INPUT_BYTES. Los estados 204, 205 y 304 responden sin cuerpo, como exige HTTP, conservando las cabeceras permitidas. La conversión de PDF a imágenes rechaza documentos de más de 2.000 páginas antes de enumerar sus tamaños, aunque solo se solicite una página.

Cuando se añade, cambia o borra un registro de una tabla

Un trigger Table record nombra una tabla, los eventos de registro (events) con los que empieza - añadir, cambiar, borrar - y filtra el registro tal como se añadió o se cambió, o como era antes de borrarse: desde la consola, la API, un agent o el paso de tabla de otro workflow. Un cambio solo lo inicia cuando cambió una columna elegida, si hay columnas de la tabla elegidas.

Pasa el registro: su record_id, el event, sus values por id de columna, los mismos valores como fields por etiqueta, con una elección como la etiqueta de su opción, before y las columnas changed en un cambio o un borrado, y el author_id de quien lo hizo. Publicarlo requiere acceso de lectura a la tabla, y nada de antes de la publicación lo inicia.

Un run iniciado así lleva la cadena de triggers por la que pasó, así que un workflow que vuelve a escribir en la tabla cuyo trigger lo inició se bloquea en lugar de entrar en bucle.

Triggers, en la propia tabla, enumera los workflows que empiezan por ella, los pausa y reanuda, y muestra lo que cada uno decidió sobre cada registro. Consulta Virtual Tables.

Desde un formulario

Test draft abre una vista previa autenticada para un único trigger Form. La URL incluye el nodo de entrada para separar formularios independientes. El envío inicia una prueba del borrador guardado con las respuestas; abra el run para comprobar el resultado. La vista previa no publica un enlace público. Los lectores pueden ver la página, pero no ejecutar el borrador.

El paso Form muestra los enlaces de prueba y publicado junto a la configuración. Appearance controla el acento, la anchura estándar o amplia y el diseño de tarjeta o página sencilla. La vista previa utiliza el mismo renderizador que la página pública. Las descripciones admiten Markdown; los campos, el texto del botón y el mensaje de éxito siguen siendo configurables. Las pruebas pueden ejecutar las acciones del workflow.

Un trigger Form da al workflow una página pública: un título, una descripción y un campo por cada campo que declara, tipado como los de Manual, con sus propias palabras en el botón y tras el envío. Publicar crea la página, y Trigger muestra su enlace para copiarlo o abrirlo. Cualquiera con el enlace la rellena sin iniciar sesión, y cada respuesta que encaja con los campos inicia una ejecución como el miembro que publicó el formulario. Los pasos siguientes leen las respuestas como payload, y la página de ejecuciones dice que la inició un formulario.

El enlace es la única credencial de la página y sobrevive a cada publicación del mismo nodo. New link lo sustituye, y el antiguo responde entonces como si no hubiera formulario; pausar el trigger cierra la página. Las respuestas que no encajan se señalan en la página y no inician nada, un campo oculto atrapa los scripts, y cada formulario admite como mucho RATE_LIMIT_FORM_SUBMISSIONS_PER_MINUTE respuestas por minuto. Ver trigger.form.

Desde GitHub

Un trigger GitHub inicia el workflow cuando ocurre algo en un repositorio: un issue, un comentario, un pull request o su revisión, un push, una release o una ejecución de Actions - lo que nombre Starts on, y solo las actions listadas, como opened, si se nombra alguna. Publicar le da su propia dirección y su secreto de firma.

Con Set up the webhook for me activado y la cuenta de GitHub de la organización conectada con permiso para gestionar webhooks, la publicación registra el hook en el repositorio y lo vuelve a registrar en cada publicación posterior; si no, muestra el secreto una vez, para pegarlo con la dirección de Trigger en Settings > Webhooks del repositorio.

Cada entrega que GitHub firma para ese repositorio, evento y acción inicia una ejecución como el miembro que publicó el workflow, con event, action, repository, sender y todo el payload. Una reentrega responde con su primera ejecución, y todo lo demás - incluido el ping de GitHub - se omite. New secret sustituye el secreto y vuelve a registrar el hook donde la cuenta lo creó. Ver trigger.github.

Desde un correo

Un trigger Gmail inicia el workflow cuando llega un mensaje al buzón de Gmail de la organización - el conectado mediante el portal Gmail. El panel del paso dice si hay un buzón conectado y conecta uno, y la publicación se rechaza hasta que lo haya. El buzón se lee en la misma consulta que dispara los triggers de Gmail de los agentes, cada minuto, y cada mensaje nuevo que encaja con todos los filtros puestos - Subject contains y Sender contains, sin distinguir mayúsculas, y Label, exacto - inicia una ejecución como el miembro que publicó el workflow.

Check for new mail every, en el bloque del buzón del paso, cambia ese ritmo (1, 5, 15, 30 o 60 minutos). Es un ajuste del buzón y vale para todos los triggers de ese buzón.

Sender contains lee la dirección del remitente, nunca el nombre visible: @acme.com coincide exactamente con ese dominio y no con sus subdominios, una dirección completa coincide con esa dirección y cualquier otro texto con una parte de la dirección. Con él puesto, el mensaje debe además pasar la comprobación de remitente autenticado - DMARC superado, o firmado con DKIM por el dominio del remitente -, así que un From que cualquiera puede escribir no inicia una ejecución. Los mensajes con la etiqueta SENT, DRAFT, SPAM o TRASH no son llegadas y no inician nada, salvo que Label nombre una de ellas.

La ejecución recibe sender, to, subject, text, snippet, labels y el message_id del buzón, además del hilo al que pertenece el mensaje: thread_id, rfc_message_id (la cabecera Message-ID), in_reply_to, references, received_at y el cuerpo html. Los tres campos de cabecera los escribe el remitente: sirven para enlazar una respuesta con el hilo, pero no prueban quién envió el mensaje. Un mensaje leído dos veces inicia su ejecución una vez, y uno para el que la organización aún no tenía sitio se vuelve a leer un minuto después. Ver trigger.gmail. Para leer el cuerpo html como texto, enlaces o lo que elige un selector CSS, vincúlalo a html.parse.

Un trigger Outlook hace lo mismo con el buzón de Microsoft 365 de la organización, conectado a través del portal Outlook. Microsoft Graph se lee carpeta a carpeta, así que el paso nombra el Folder que vigila - la bandeja de entrada si no dice otra - y, para leer un buzón compartido que la cuenta conectada puede abrir, un Shared mailbox. Los filtros son Subject contains, Sender contains, Has attachments, Importance y Category.

La primera lectura de una carpeta empieza en el momento en que se publicó o se encendió por última vez el workflow, así que el correo que ya está allí no inicia nada. Nombrar un buzón compartido que el grant de Microsoft de la organización pueda abrir exige el permiso para gestionar conexiones, como en los triggers de agente de Outlook; un workflow que ya escucha uno lo conserva en publicaciones posteriores, y cambiarlo exige el permiso otra vez. Si Outlook dice que la carpeta ya no se puede leer, el workflow se apaga y el registro de auditoría dice por qué.

La ejecución recibe los mismos campos que una de Gmail, con labels con las categorías del mensaje y mailbox con el buzón compartido del que vino. Ver trigger.outlook.

Los dos triggers de correo aceptan entrada de fuera: cualquiera puede enviar un mensaje al buzón, así que enlaza lo que la ejecución hace con él como harías con un webhook.

Los attachments de un mensaje listan el nombre, el tipo declarado y el tamaño de cada archivo; un buzón lista como máximo 20 por mensaje, y un cuerpo text o html se lee hasta 20.000 caracteres. Una ejecución que inició el buzón los guarda como archivos del run, y cada uno lleva su file y stored: true. De los adjuntos listados solo se consideran los 10 primeros, hasta 25 MiB en total, y cada uno debe caber en el límite de tamaño de subida del chat, en la lista de tipos de archivo permitidos y en la cuota de almacenamiento de la organización.

Uno que se deja fuera lleva un reason: too_many (pasados los 10 primeros), too_large, type_not_allowed, quota o unreadable - el buzón respondió 400, 401, 403 o 404 para él, o su grant falta, está apagado o no se puede renovar. Una ejecución de prueba no lee nada del buzón, así que sus adjuntos son not_fetched. Cuando el buzón falla de una manera que un reintento puede curar, el paso falla con MAIL_ATTACHMENT_UNREACHABLE y se reintenta.

Desde un mensaje en un canal

Un trigger Channel message entrega al workflow los mensajes de un bot de Slack, Mattermost o Telegram. Cada mensaje que el bot habría respondido con su propio agente - pasó la política de acceso del bot, su remitente fue admitido y, en un canal, nombró al bot - inicia una ejecución como el miembro que publicó el workflow, si encaja con Where y Only when the message contains. Un mensaje que nombra a un agente por @handle sigue llegando a ese agente, y uno que no encaja lo responde el agente del bot como hasta ahora.

El trigger entrega text, sender - con el miembro que vinculó, si lo hizo - y el channel_id y el thread_id que admite un paso Send a message de la misma plataforma, así que la respuesta llega al hilo del que vino el mensaje.

Los triggers de Slack y Mattermost entregan un hilo incluso con un mensaje de nivel superior, porque el propio mensaje lo abre, así que una respuesta enlazada va en el hilo; un trigger de Telegram entrega un tema solo dentro de un tema de foro.

Un paso Send a message añadido después de un trigger Channel message empieza como el bot del trigger, con channel_id y thread_id enlazados, cuando las plataformas coinciden. Los mensajes de un bot inician como mucho un workflow, y escuchar a un bot requiere channels:manage. Una nota de voz llega como su transcripción; los demás adjuntos no se entregan. Ver trigger.channel_message.

Cuando otro workflow lo llama

Un disparador Called by a workflow crea un workflow que otros ejecutan como paso: lógica compartida - enriquecer un lead, abrir un ticket - en un solo lugar. Declara sus campos como Manual, y el paso Run a workflow de otro workflow, que solo ofrece workflows publicados así, lo inicia con la entrada que vincula, comprobada antes contra esos campos.

El paso espera a la ejecución llamada y entrega su output, o sigue enseguida con Wait for it to finish desactivado. La ejecución llamada queda vinculada a la que llama en ambos sentidos - su página dice Called by esa ejecución, y la línea del paso en la página de quien llama abre la ejecución que inició - y aparece en las páginas de ejecuciones como cualquier otra. Una ejecución iniciada por un workflow de errores dice qué ejecución fallida la inició. Una llamada de vuelta a un workflow que ya se ejecuta en la cadena, o con más de cinco niveles, se rechaza.

Los workflows llamados heredan el presupuesto restante del llamador y el plazo más cercano. Su gasto cuenta en el total del llamador; own_cost muestra solo los cargos directos para evitar duplicarlos al sumar registros. Con un presupuesto limitado debe mantenerse la espera hasta finalizar. Cancelar el llamador o revocar su acceso detiene al hijo antes del siguiente paso; una solicitud externa en curso puede terminar. Reintentar una llamada reutiliza los pasos exitosos del hijo original con su versión fijada. Si ese hijo sigue activo, debe terminar o detenerse primero. Los archivos de salida se importan explícitamente al llamador y el acceso se comprueba al reanudar.

El gráfico diario y las estadísticas por paso del llamador también incluyen los cargos de las ejecuciones llamadas.

La recuperación se detiene si falta la salida de un paso exitoso, se eliminó la ejecución llamada o su historial de reintentos es cíclico. No repite efectos para reconstruirlo. La cancelación, el presupuesto agotado y los permisos revocados del hijo siguen siendo fallos que una rama de error no puede ocultar.

Desde un agente

Configura nuevas herramientas del agente mediante AgenticOS MCP y selecciona las herramientas necesarias para descubrir workflows, run_workflow y leer ejecuciones. Pasa las entradas declaradas del workflow publicado como fields y consulta la ejecución hasta que termine. MCP usa los permisos del miembro solicitante y mantiene la aprobación de escrituras. Un agente dentro de un workflow llama a otro mediante un nodo workflow.run. Los bindings existentes conservan sus IDs explícitos, límite de espera y permisos para acciones de páginas.

Una ejecución sin un miembro detrás (un visitante de un widget, un embed o una página alojada, un remitente de canal no vinculado, la entrega de un trigger de eventos de un agente) no inicia ninguno.

Desde una app

Una página publicada puede iniciar un workflow que su agent ha vinculado y que arranca desde Manual o API request. La página solo lo pide. Al miembro que la ve se le muestra un diálogo con el nombre propio del workflow y cada valor de entrada, y el run empieza solo cuando confirma. Es suyo: su acceso, su budget y su página de runs, comprobado, facturado y auditado como uno iniciado desde Start a run, y sujeto a la misma cuota de admisión. Un run sin ningún miembro detrás, o desde una sesión suplantada, no inicia ninguno.

La página de runs dice que un run así lo inició A page, y Started by filtra por él; por la API su triggered_by es app. El run también registra la página y la versión que miraba el miembro, y un reintento las conserva. La página lee de vuelta solo el estado del run, su respuesta y la primera línea de un error.

Cuando otro workflow falla

Un disparador On failure of a workflow crea un workflow de errores. Elegido como workflow de errores de otro en sus Settings, se inicia una vez por cada ejecución real de ese workflow que termina en fallo, con el run_id de la ejecución, su workflow_id y workflow_name, el step_id y step_name del paso que falló y el error con que terminó. Se ejecuta como el miembro que lo eligió, que aún debe poder ejecutarlo. Una ejecución de prueba no inicia nada, ni tampoco el fallo de una ejecución que ya es un workflow de errores, así que un workflow de errores que falla nunca vuelve a iniciarse.

Cuando algo sale mal

Lo que promete un run. El resultado de un paso y el envío de los pasos siguientes se guardan juntos, así que un worker que se detiene entre pasos no pierde nada: otro retoma el run donde estaba. Un worker que se detiene dentro de un paso deja un intento cuyo final nadie vio. Un paso que se puede repetir sin riesgo se vuelve a intentar. Una escritura en una tabla repite su primera escritura a través de su recibo en lugar de escribir dos veces, y una notificación se envía una vez. Un paso que puede haber actuado ya en otro sitio y no promete nada más - ejecutar un agent es uno - nunca se repite por sí solo: el run se detiene como Needs attention, para no pagar un modelo dos veces ni enviar un mensaje dos veces sin que nadie lo decida.

Nada más ocurre exactamente una vez. Una llamada HTTP, una subida o una escritura de archivo pueden repetirse tras una detención así, de modo que un sistema receptor que no debe ver una petición dos veces necesita su propia clave de idempotencia. La promesa de reintento de cada paso está en la referencia de nodos.

Lo que ves	Por qué	Qué hacer
Needs attention	Se interrumpió un paso que pudo haber actuado, o dejó de esperar y nada lo despierta	Comprueba si su efecto ocurrió y resuelve el paso en el run con Resolve: ejecutarlo de nuevo, usar un resultado informado tarde, tomar su camino de error o hacer fallar el run. Cancelar el run y luego Retry from failed step empieza de cero
PRINCIPAL_REVOKED	El miembro con el que actúa el run perdió el acceso o su cuenta se desactivó	Que un miembro que pueda ejecutar el workflow lo vuelva a publicar, para que su trigger se ejecute como él
WORKFLOW_TRIGGER_MISMATCH	El run se pidió por una vía que no es su trigger en vivo: a mano o por la API para un workflow que empieza por un webhook, o en el chat para uno que no empieza por un mensaje del chat	Inícialo como dice su trigger, o prueba el draft, que acepta cualquier trigger
INVALID_BINDING	Un valor no encajaba en el campo al que estaba enlazado	El error del paso nombra el campo; corrige el enlace o el valor anterior
REVISION_CONFLICT	Alguien cambió un registro después de que el paso lo leyera	Encamina el error del paso con error.handle hacia una lectura nueva
El historial de un trigger de tabla dice Blocked	El run se habría iniciado a sí mismo de nuevo, o su cadena llegó demasiado hondo	Consulta Triggers
Un webhook responde 403	La firma no coincide con el cuerpo, o el miembro con el que se ejecuta ya no puede ejecutar el workflow	Firma exactamente los bytes enviados con el secreto actual, o que un miembro que pueda ejecutarlo lo vuelva a publicar

Teclado y accesibilidad

Cada parte del editor tiene una ruta que no necesita puntero. El selector de pasos es una lista que recorres con las flechas y de la que eliges con Enter, cada control de solo icono lleva una etiqueta hablada, y el lienzo toma el foco de teclado para que puedas tabular por sus pasos y conexiones. Una conexión se puede hacer desde el teclado: empieza una en un nodo y luego termínala en un destino compatible.

Los atajos del lienzo se disparan solo mientras el foco está dentro del editor, así que nunca roban una tecla a un campo en otra parte de la página:

Arrastra con el botón izquierdo para seleccionar objetos. Mantén Mayús al arrastrar para mover la vista; los botones central y derecho también la mueven. Ctrl/Cmd + A selecciona todos los objetos del ámbito actual, incluidas las notas en el nivel principal.

Las ejecuciones observadas muestran un pulso hacia el paso activo y un barrido en el borde de su tarjeta. Un breve barrido al finalizar permite leer ejecuciones rápidas sin cambiar su estado ni sus tiempos reales. Las ejecuciones históricas permanecen quietas; la preferencia del sistema de movimiento reducido desactiva la animación. La duración, el coste y los pasos completados quedan alineados, con la hora de inicio junto al estado.

Teclas	Hace
Tab	Abrir el selector de pasos
Ctrl/Cmd + Enter	Lanzar una ejecución de prueba del draft, esté donde esté el foco en la página
Ctrl/Cmd + Z	Deshacer
Ctrl/Cmd + Shift + Z, o Ctrl/Cmd + Y	Rehacer
Ctrl/Cmd + C	Copiar la selección
Ctrl/Cmd + X	Cortar la selección
Ctrl/Cmd + V	Pegar, desplazado para no cubrir el original
Delete o Backspace	Borrar la selección
Escape	Cancelar una conexión en curso
?	Mostrar estos atajos

Un pegado obtiene ids nuevas y reasigna los bindings entre los pasos copiados, así que los pasos pegados leen unos de otros y no de los originales. Cada atajo de edición es inerte mientras el editor es de solo lectura - una versión publicada, o View only -; Escape sigue cancelando una conexión perdida, y ? sigue mostrando los atajos.

Copiar y pegar tienen tres límites:

• Un paso con bindings lee de donde leía. Un paso copiado conserva sus bindings. Uno que lee de un paso que no copiaste sigue leyendo del original, pero nada conecta el paso pegado con él, así que no valida hasta que los conectes. Selecciona ambos pasos para copiar el par, y la copia leerá de su propio paso anterior.
• Una conexión viaja solo con sus dos pasos. Seleccionar solo una conexión y copiar no hace nada.
• Los atajos pertenecen al lienzo. Funcionan mientras el foco está en el lienzo, y hacer clic en cualquier parte de él — un paso, el lienzo vacío, una conexión — lo mantiene ahí. Con el foco en los ajustes de un paso o en el selector de pasos, las teclas son de esos campos, así que haz clic en el lienzo antes de pulsarlas.

Los adjuntos de imagen de un agente comparten un límite de 20 MB, comprobado antes de cargar cada archivo, incluidas referencias repetidas. Los resultados MCP eliminan cabeceras de autenticación y credenciales del texto y de los datos anidados. Los nombres se normalizan antes de guardarlos, conservando extensiones dentro de 255 caracteres. Los campos CSV pueden usar el límite del paso, hasta 50 MB; los rechazos del analizador tienen un tipo explícito.

El bucle mide en SQL los últimos resultados yield y errores no gestionados antes de cargarlos. WORKFLOW_FOREACH_MAX_OUTPUT_BYTES vale 10 MiB por defecto, incluido el coste de la colección; superarlo produce FOREACH_OUTPUT_TOO_LARGE. Para datos grandes devuelve valores menores o referencias a archivos. La colisión entre una clave de resumen y un campo de grupo produce SUMMARY_KEY_COLLISION.

Las entradas, configuraciones de borrador y resultados fijados deben poder representarse en JSONB de PostgreSQL. Un resultado no almacenable produce INVALID_NODE_OUTPUT, sin reintento automático y conservando los costes. Una acción externa puede haberse completado; compruébala antes de repetir el nodo.

Los resultados en línea comparten WORKFLOW_NODE_MAX_OUTPUT_BYTES (10 MiB por defecto): resultado del intento, salida y respuesta webhook juntos. El exceso da NODE_OUTPUT_TOO_LARGE, conserva costes y no se reintenta automáticamente. Split out comprueba el número expandido (máximo 10 000) antes de copiar y estima conservadoramente los bytes de campos repetidos. El exceso da SPLIT_OUTPUT_TOO_LARGE. Para datos mayores, usa referencias a archivos.

Una comprobación previa de los campos del modelo rechaza valores grandes repetidos antes de que la serialización copie el resultado completo.

Los sockets de workflow conservan la identidad y los permisos de la clave de organización en cada frame y consulta del flujo. Una clave de lectura no inicia ejecuciones; las claves no acceden a ejecuciones privadas ni escriben en chats personales. Los workers conservan sus límites; la revocación cierra el flujo en la siguiente consulta.

Las galerías de skills y contexto del agente integrado cargan todas las páginas de metadatos y permiten reintentar errores. Las nuevas entradas de evaluación cumplen los límites JSONB y de bytes de admisión; los casos antiguos demasiado grandes siguen legibles para eliminarlos. Los lotes fallidos de PDF o sandbox eliminan sus archivos anteriores, conservando los existentes. Los scripts fallidos mantienen su registro diagnóstico.

Resumen

• Un workflow es un draft que editas y una versión publicada e inmutable que se ejecuta — empieza uno desde un trigger o una plantilla, y Duplicate copia un draft en un workflow nuevo.
• El selector de pasos añade pasos - desde +, la salida de un paso o un clic derecho; el lienzo los conecta y rechaza una conexión entre puertos incompatibles.
• Una arista fija el orden y los bindings llevan los valores; conectar puertos de la misma forma crea los bindings por ti.
• Un parámetro es un valor o datos de un paso — Data los lee de una salida previa alcanzable y de tipo compatible, o los mete en un texto.
• El draft se guarda solo, y una edición desde dos sitios levanta un banner con Overwrite o Reload.
• Publish se bloquea mientras un problema persiste y vuelve a validar en el servidor; las versiones anteriores quedan visibles en solo lectura, y Restore to draft vuelve a convertir una de ellas en el draft.
• Cada acción tiene una ruta de teclado, y los atajos de edición son inertes en una versión publicada de solo lectura o en View only.
• Un workflow puede tener varios triggers independientes, como Manual, Webhook y Schedule. Añadir uno conserva los inicios y conexiones existentes. Cada run elige un inicio y ejecuta solo su rama alcanzable; no espera a otro trigger. Un paso compartido solo puede leer datos disponibles desde todos los inicios que llegan a él. Normaliza las entradas distintas por separado antes de compartir pasos.
• La política de un paso fija sus intentos, su límite de tiempo y si sus fallos salen por un puerto Error; el cuerpo de un paso For each se ejecuta de Loop item a Loop result una vez por elemento.
• Runs enumera cada run, Start a run prueba el draft o ejecuta la versión publicada, y un run muestra su grafo paso a paso tal como ocurrió.

Las nuevas automatizaciones pueden enviarse con prepare_workflow_draft: una aprobación crea una tabla privada y el grafo completo de forma atómica. Una validación fallida no deja ninguno de los recursos. check_workflow_draft comprueba el grafo y sus referencias sin ejecutar pasos ni solicitar aprobación de escritura, e indica expresamente que las integraciones siguen sin verificar. Las pruebas con acciones requieren aprobación. Las pruebas de horarios aceptan datos sencillos y añaden la fecha del evento y los valores configurados. La página del run distingue las pruebas de estructura de la verificación de integraciones.