Test runs

Test run in the workflow workspace fires the workflow immediately with its pinned sample payload. There is no confirmation step: one click, and a run appears.

A test run is a completely real run. Same dispatcher, same queue, same worker, same engine. It gets a real status, a real timeline, real steps and a real cost. Nothing about it is simulated, and there is no second execution path hiding behind the button.

What a test run does not do is change the workflow's standing. It earns no readiness toward codification, it cannot degrade the workflow's health, and it opens no work item for you to clear. That is the whole of the difference.

Telling a test from a real run

A test run carries a test chip in the runs list and a test badge on the run screen. Accept and Reject are not offered on it, because a test can never become a training example and a button that can only fail is worse than no button.

Two things people expect to be tests and are not:

• Run now, the play button on a workflow row, fires the published workflow for real. It is the on demand "go" button, not a rehearsal. It appears only on a published workflow that can be fired without an incoming event.
• A live trigger firing while you happen to be watching is a live trigger. Nothing about being observed makes a run a test.

Draft or published

The workspace decides which version of the instructions a test fires: the draft you are working on with the assistant, or the published one. Fire against the draft and the run is pinned to an immutable snapshot of it, labelled like v1.2, and the toast names the label so you know exactly what just ran.

A snapshot never advances the version counter and can never be promoted, so testing a draft cannot publish it by accident. Publishing stays a deliberate act.

It fails at the click, not in a worker

Anything that would make the run impossible is checked before anything is queued. An empty set of instructions, a draft requested with no interview open, a custom payload that is not a JSON object, a payload whose keys collide with the pinned sample: all of these come back as an error where you clicked. You do not get a success toast and then silence.

Steering a test with a note and a payload

Under Trigger test payloads in the sidebar there is a disclosure row called Add a note or custom payload. It holds two optional fields:

• Note to the agent. Free text saying what this test stands for. For example: assume it is the 10am fire.
• Custom payload. A JSON object merged into the test payload as its own data. Keys must not collide with the pinned sample.

Both ride alongside the pinned sample rather than replacing it. If your payload supplies the trigger's fire time itself, that value is used rather than a synthesized one, which is how you exercise a time dependent path under test.

That elevation is deliberate, and so is what we refused to build instead. There is no bypass flag and no "force execution" switch, because inside a workflow a flag that skips a check is indistinguishable from a flag that skips real business logic. A guard in the process is a business rule, not an obstacle to testing. So the only lever a test fire has is the same lever a real trigger has, its payload, delivered at a tier the instructions themselves speak from.

Where sample payloads come from

The payload library has two tabs.

Generated holds the samples the interview drafted when you set up an event trigger. Click one to pin it, and the pinned sample is what Test run fires.

Past holds the payloads real scheduled and webhook runs actually received. Click one and it becomes a pinned copy. This is the closest thing to re-running a specific real case: you take that case's input and fire a new test with it. The result is a new run with its own record, never a replay of the old one.

If the workflow runs on demand or on a schedule, there is no payload to pin and the library says so.