For the complete documentation index, see llms.txt. This page is also available as Markdown.

Run Panel

Run is the builder surface for executing the current Workflow draft and inspecting what actually happened.

It is one tab in the same right-hand panel as Feedback, Test and Publish. Run is for an execution you are working through now; Feedback is attached to a run; Test opens the repeatable checks headed Evaluations; Publish controls version and live publication state.

A Run is a real execution

Running a Workflow from the builder is not a dry simulation. Actions can call connected systems and cause external side effects such as writes, messages or other changes.

Opening the Run panel can itself start execution. In particular, an App-triggered Workflow with no trigger form fields and a single user-facing step can start its draft run as soon as the Run panel opens. Do not treat opening Run as a side-effect-free inspection step on those Workflows.

Before opening or running a draft, use test-safe inputs and understand which connected actions can mutate external systems.

A completed Draft run showing the submitted trigger input, run feedback controls and per-action timings.

What to inspect

A useful run review answers four questions:

  1. Did the expected path execute?

  2. Did each important step receive the right input?

  3. Did it produce the expected output or external change?

  4. Did the business post-condition actually become true?

A technically successful execution is not always proof that the operational outcome completed. When the external system provides a confirmation, identifier or downstream state, verify it where the process requires that evidence.

Traces and step evidence

Use run or trace detail to inspect the execution of individual actions. This is where you diagnose wrong inputs, unexpected branches, external errors or an output that looks plausible but was produced for the wrong reason.

For broader historical execution evidence, use Monitoring rather than treating the current Run panel as the system-wide operational history.

Run vs Test

Use Run while iterating interactively on the draft. Use Test when you want a repeatable case with defined inputs and checks.

Both execute real Workflow behaviour. Neither should be treated as inherently side-effect-free.

After the run

If the behaviour is correct, continue to the Test and Publish guidance. Publishing moves the Workflow from Draft into a Published version, but live traffic also depends on the current active/default semantics and any deployed triggers or schedules.

Last updated

Was this helpful?