Workflows and runs

A workflow does the same thing to many inputs. Rewrite forty prompts, describe two hundred images, run one question against a dozen files — anything where the work is identical and only the input changes.

What a workflow is

An ordered list of steps. Each step calls one operation with parameters, and may name its result so later steps can use it.

Values are substituted with ${name}. A step that writes its output as draft makes ${draft} available to everything after it.

Operations cover: running a prompt through a model, reading a file, writing one, appending to one, searching the web, pulling a fragment out of text with a pattern, and generating an image. The editor lists what is available and what each one takes — the set comes from Zero itself, so the form always matches what will actually run.

Running any connected tool. Beside the image step there is a general one: name a tool as Settings → Integrations lists it, say what it should produce (image, video, speech, a transcript), and pick one of its models. That much the step form asks for.

A tool's own knobs are written as options. plus the knob's name — options.voice, options.cfg. They are not listed in the form, because which knobs a tool has is the tool's business and not ours: a graph engine reads them out of your own workflow files, and they change when you edit those files. The integration's page is where you can see what a given model offers. The step form has no way to add one yet — until it does, a workflow that sets them is edited as a file.

The image step stays for the things it already did — size, quality, how many — which the general step deliberately does not carry. A first frame for image-to-video is in the same position: it is one of those fixed fields, so a video started from a workflow is text-to-video only for now.

A workflow is a straight line. No branches, no conditions, no loops inside a run. That is a deliberate limit: the thing that makes a run legible is that every row went through exactly the same steps.

Inputs are not part of the workflow

A workflow does not contain its inputs. It reads ${variables} it never produced, and those become its signature — the columns every input row has to supply. Zero works this out from the steps; there is no separate place to declare parameters and no way for the two to disagree.

A row is one set of values: one pass through every step. A run is a workflow plus its rows.

Building the rows

You can type rows directly, or generate them with a matrix: name some axes, and the rows are every combination.

An axis is either a list of values you write, or a source that produces them — listing the files in a folder, for instance. A source can publish extra columns alongside the value, so a file axis also gives you the file's name, extension and folder without your having to split anything.

Expand shows the rows the matrix produces, before anything runs. This is the point of a separate button: finding out that two axes multiply out to 900 rows is cheap here and expensive one screen later, where each row is a full pass of every step. Individual rows can be struck out — they stay visible but do not run.

A run is capped at 500 rows. Over that, narrow the matrix or strike rows out.

Rows you have assembled last as long as you are working, but they are not saved with the workflow — the workflow is the definition, the rows are this run's argument.

Running

Check validates without running: unknown parameters, missing required ones, a ${variable} nothing provides.

Run starts the work in the background. While it runs you get progress and the row count; when it finishes, the per-row results appear as a grid. Several rows are processed at the same time, and a row that fails does not stop the others — you get the failures listed with everything that succeeded.

Cancel stops a run in progress.

Runs are background jobs, so they survive you switching to another tab, and you can see them all in the Jobs tab.

Running one from an object

A workflow does not have to be started from the Workflows page. A schema can bind one to a button on every object of its type, filling the workflow's signature from that object's fields — one object, one row, one run. It appears in Jobs and counts against the same budget as any other run. See Views and actions.