Runs in the editor

The editor can show any run of an automation on the canvas, so you read a run where you fix it. From there you can run your draft on the same data with writes held, and read what each block did. This guide is for people who build automations.

Open a run

The canvas shows a run only when you open one. Outside that view, blocks carry no run status, only validation issues, so an old result never looks like the state of your draft.

You open run view in any of these ways:

Runs in the editor header lists the automation’s newest live runs. Pick one, or choose All runs to go to the Runs page. A red dot on Runs means recent failures.
Open automation on a run in the Runs page.
Run in the editor header. Once the run starts, the editor opens it.
Run draft or Run from here. The new run opens when it starts.

The run bar

A bar between the header and the canvas names the run you are looking at: its status, its name, what happened and when, for example “Run 4f2a91c0 · failed at Check the order · 8m ago”.

Switch run opens the same list of recent live runs as the header. To get back to a draft run, use From Run on a run started from it, or find it on the Runs page and click Open automation.
Back to latest leaves run view and returns to your draft with no run on the canvas.
A Draft run label marks a run of the draft, and From Run links to the run it started from.
A warning under the bar means part of the run’s record is missing. See Incomplete records.

Read the canvas

In run view, each block shows how it did in that one run. Statuses never mix runs.

On the block	Means
Green check	Run succeeded.
Red mark	Run failed.
Blue mark	Write held: a draft run did not perform this block. See Held writes.
Grey or amber mark	Block was skipped, stopped because the run stopped, or needs review.
Dimmed	The block did not run in this run.
Changed	The block was edited since the published version this run used. Its setup on the canvas may not be what ran. Draft runs show no marks.

The Run tab

In run view, a selected block has a Run tab beside Setup and Samples. It shows the block’s status in this run, its Input and its Output. If this is the block the run failed at, it also says why. If the block was edited since the run, it says Changed since this run.

A block's Run tab showing the failure reason, the Run from here and Capture as sample buttons, and the block's input.

Anyone who can read the automation’s runs sees the values, including read-only roles such as Workspace viewer. Only secrets are hidden: a field a block declares secret reads “Hidden: secret field.” Other gaps say what happened:

You see	Means
Did not run	The run never reached this block.
Not recorded.	The value could not be saved. See Incomplete records.
Too large to show here.	The value is too large to show in one response, or was too large to keep.
Removed by retention.	The run is past the retention period.
Reused value expired.	The value came from an earlier run whose values have since been removed.

Two actions sit at the top of the tab:

Capture as sample keeps this block’s output in this run as its example values on the Samples tab.
Run from here starts a draft run from this block. See Run from here.

Run draft

Run draft in the editor header runs what is on the canvas. Pending edits are saved first, and the run uses that saved version, so later edits do not change it.

Choose where the trigger’s input comes from. Options that do not fit are dimmed, with the reason listed below them.

Option	Uses
A past run	The trigger input of the run you are viewing once it has finished, or else the newest finished run that reached this trigger.
Pinned sample	The example values on the trigger’s Samples tab.
Fill the form	The form an Operation trigger shows. Forms with file uploads are not offered.

Run draft will not invent an input: with none of these, its tooltip says “Pin a sample on the trigger or run the automation once to run the draft.” Running a draft needs a role that can edit the automation, and up to 5 draft runs can run at once for one automation.

If some blocks have no pinned output, last real output or plan to pass on, the dialog says “The run may stop at these blocks” and lists them, with Draft with your assistant to fill in their example values. See Held writes.

Draft runs never join failure groups and do not send failure notices. Find them on the Runs page with runs: Ungrouped and mode: Draft runs.

What runs for real

In a draft run	What happens
Reads, such as an HTTP `GET` or `HEAD`	Real calls. They reach the other system, using the block’s connection.
Computation, such as Parse JSON or Condition	Runs as usual.
Model calls	Real calls. Each draft run calls the model again.
Prompts that use tools	Held as a whole, because the tools could write.
AI Agent	Calls the model and its read tools for real. It gets no write tools.
Writes, sends and deletes	Held. Nothing leaves Lainstack.
Wait	Skipped. The run goes straight on, and the block reads “Wait skipped in a draft run”.
Approval and Checklist reviews	Use the block’s pinned or last real decision. With neither, a real escalation waits for an answer.
Run automation	Starts the called automation’s published version with its writes held, and its pins do not apply.

Held writes

A held block performs nothing. It records what it would have done, for example “Held: this would send to Post the order through Order API. Nothing was sent.” The later blocks still need its output, so the run takes the first of these it finds:

A held block always stays held. These only decide whether the blocks after it get to run.

Its pinned output: the example values on the block’s Samples tab.
Its last real output: what the block produced the last time a live run reached it.
Its plan: what the block says it would return. Only some blocks give one, such as the BoxTop write blocks.
None of these: its branch stops there. The run bar says “stopped at” the block: “write held, no pinned or last real output”. The run still ends without a failure, because nothing went wrong, but the blocks after it never ran.

A review stands in the same way, but only for a decision someone really recorded. An Approval takes the decision from its pinned output, or the decision of its last real run, and the run keeps this run’s data to review. A Checklist’s output holds no decision, so a pin cannot stand in for one: it takes the path its last real review took, keeping this run’s results. A past Checklist that had no findings decided nothing. The block reads “Stand-in decision” and opens no escalation. With no decision to use, the review pauses for a person as usual.

These are stand-ins, not real responses. The other system was never called. The Run tab says so on the block, for example “Output from the pinned sample, not a real response.” A draft run that passes on stand-ins shows that your automation handles that shape of data. It does not prove the real call would work or would answer that way.

Reads are different: they are real calls, and their output is what the other system really answered.

Some stand-ins cannot be used. The run then tries the next one, and the branch stops if none is left:

A pinned output that holds files. A pin that does not match the block’s outputs fails the block with pinned_output_invalid; edit the pin or remove it.
A last real output that holds files or tables, that comes from a block with secret outputs, or that no longer matches the block’s outputs.

Run from here

Run from here on a block’s Run tab starts a draft run from that block of the viewed run. Earlier blocks are not run again: their outputs are reused from the source run. The block and everything after it run on your draft, with writes held as above. It is the main action on the block a run failed at.

The button is unavailable, with the reason in its tooltip, when:

The block is inside a loop: “A run cannot start inside a loop. Start at the loop step, or before or after it.”
The run has not finished, or retention has removed its data.
The draft has validation issues.

If the source run’s record is incomplete, Run from here asks first, since later blocks may get empty values. Choose Run anyway to go ahead.

A block that declares secret outputs cannot be reused, since its secrets were never stored. The draft run starts at that block or earlier instead. A held block reuses the output it passed on in the source run, so to try an edited pin, start at that block or earlier.

Read the result

A draft run started from another run says so in the run bar: From Run and the block it started at. Click it to go back to that run. Select a block to read its input and output on the Run tab. A reused block shows the values from the earlier run. A held block is marked Write held and says what stood in for its response, or that it had nothing to pass on.

The Samples tab

A block’s Samples tab holds its example values, also called its pinned output or pinned sample. Later blocks map from them, previews show them, a trigger’s values can start a draft run, and a held write passes them on.

A block's Samples tab with example values in one field per output, and the Draft with, Clear and Capture from last run buttons.

You never edit JSON here. The tab shows one field per output, each with a control for its type: text, number, a switch for yes or no. Records and lists fold under their row, and lists have Add item. A block whose fields depend on its setup has Add field: name the field, then choose Text, Number, Yes or no, Record or List. Hover over a field to remove it, and use Clear to remove all the example values. A block such as Assert says “This block has no output.”

There are three ways to fill the fields:

Capture from a run. Capture from last run copies the block’s output from the latest run. In run view the button reads Capture from this run and copies from the viewed run. Capture as sample on the Run tab does the same. While there are no example values yet, a run’s values show greyed out; editing a field keeps them. An output over 128 KiB cannot be captured.
Type them in. Fill in or change any field. Each edit saves when you leave the field.
Draft with your assistant. Draft with followed by your agent’s name opens the chat with the block attached and a request to draft its values. The agent uses the block’s declared outputs, its settings and any earlier values it can read, and pins the result. You need a workspace agent for this button to show, and the agent needs write access.

Drafted values are marked: “An Agent drafted these values, so they may not match a real response. Editing a field removes this note.” Check them before you rely on them. Capturing from a run also clears the note.

If your values have drifted from what really happens, the tab says “These example values differ from the last run.” Capture again, or keep them if the difference is on purpose. Publishing does not send pins to the live version, so they never reach a real run.

Debug a failed run
Recover failed runs: test a fix on many runs, then resume them.
Runs