Workflows

Workflows are visual graphs of blocks and links. Each run starts at the main (start) block, follows connections, and optionally returns structured data. They are distinct from agents (LLM-driven assistants). Use a workflow when the path is explicit; use an agent when the model should choose tools.

Open Build → Workflows for workspace-wide (root) graphs. Open an agent builder and use the Workflows panel for graphs nested under that agent.

When to use

• Automate a fixed sequence (conditions, loops, table I/O, notifications)
• Expose a typed tool that agents, functions, widgets, and event handlers can call
• Drive conversational UI on the chat channel (prompts, messages, human-in-the-loop waits)

Create a workflow

Open Build → Workflows (or the agent Workflows panel) and click Create. You can also Build with AI via Studio.

1. Enter a Name (required) and optional Description.
2. Pick a Channel (locked after create).
3. Create — Vettero opens the detail page with an empty graph (start block only).

Root workflows open the full builder from Open builder. Nested (agent-scoped) workflows edit inline in the panel.

Configure the workflow

On the detail page:

Delete moves the workflow to Trash. System-managed event handler flows cannot be deleted here — disable or delete the handler instead.

Open the builder

Open builder (or Edit on a nested workflow) loads the canvas: a block palette on the side and the graph in the center. Drag blocks onto the canvas and connect handles. Use Save when the graph is valid.

The Start block is always present. You cannot delete it. Its config holds name, description, input schema, and output schema.

Work with blocks

See Blocks for type pages, grouped like the builder palette. Shared rules below apply to all of them.

The palette groups blocks by folder (Basic — Output, Input, Context, Condition, Loops, Module, Data Operations, Utility — plus Table, Chat, File, Knowledge, System, Tools, User, and connected services). Search the palette instead of memorizing types.

System palette folders include Send Notification (in-app bell inbox; does not pause the run), Form Link (private form URLs), and Share Agent (hosted Web chat URLs).

Anatomy

Connect source of one block to target of the next unless the inspector or handle label says otherwise (for example a condition’s false outlet, a loop’s callback body, or an Error outlet into Branch errors).

Catchable block failures continue on Error when that outlet is connected. If it is not, the error bubbles to Try On error, or the run fails. Unexpected thrown Error values and platform limits are fatal: they skip Error / On error, still run Try Always when possible, then abort. See Error.

Variables and the data pipe

Config fields can be a fixed value or a variable path. Paths resolve against the run context at that block.

How a block treats the pipe:

Bind only paths that exist in that block’s context. Missing paths resolve as empty.

Scope, loops, and nested bodies

Most blocks run on the main path after start. Loops, async, and similar types expose a Callback outlet. That outlet is a new callback scope, not a continuation of the main path.

Connect Callback to a Lambda block (lambda.start). Blocks after Lambda run inside the nested body. Named variables from outside still work. args.* become that handle’s callback values. Lambda puts the same object on pipe.value.

• Nested bodies cannot jump back onto the main path except through the parent block’s normal outlets.
• A Return inside a nested body returns from that body (matching the handle’s return shape), not from the whole workflow.
• The main path’s Return block is what callers receive, and it must match the workflow Return schema.

Some blocks are valid only on the main path, only inside a callback, or in both. Lambda is callback-scope only. The builder rejects invalid placement.

Channel and human-in-the-loop

Each block type lists which workflow channels it supports. Chat-only blocks (prompts, carousels, many inputs) cannot sit on a general graph — switch the workflow to chat, or pick a general-capable block.

Human-in-the-loop blocks pause the run until a person answers (chat input, upload, rating). Use them on chat workflows with a live session. A general run (agent tool, widget, mapped event) has no user to wait on; those waits fail for callers such as vt.runWorkflow.

Structured input and output

Set Arguments when callers pass parameters. Downstream blocks read args.<property>. Start also puts the input object on the pipe for the first step.

Set Return when callers need a result. Defining the schema is not enough: every completing path on the main graph must reach a Return block whose mapped fields match that schema (exact property names). Branching paths each need a Return (or merge into one).

Omit both schemas for side-effect or UI-only chat flows that do not return data to a caller.

Run and attach

Callers pass an object matching Arguments. runWorkflow waits for completion and fails if the run errors or sits in human approval.

Limits

• Channel is chosen at create and cannot change.
• Chat-only and HITL blocks are invalid on general graphs.
• Integration blocks need a connected service with the right capability.
• System-managed event-handler workflows cannot be renamed or deleted as ordinary workflows. Mapping-mode handler graphs are not free-form edited.

Where workflows are used