Running a workflow yourself

Some work has no schedule and no event behind it. You do it when you decide to. That is a real trigger choice, and the interview will set it. The workspace then marks the workflow as manual and on demand.

Even a workflow that runs on a schedule or an event can be started by hand. The on-demand path stays open whatever else is armed, and it survives a pause.

Run now

The workflows list has a play button at the end of each row, labelled Run now. Click it and you get a toast saying the run started.

It is the real thing, not a rehearsal. It fires the workflow's published SOP with normal guardrails and an empty payload, and the run appears in the run list like any other.

The button only appears when it would actually work, which means:

• The workflow has been published at least once.
• Its armed trigger is manual or a plain schedule.

An event-triggered workflow shows no Run now button at all. That is deliberate. A manual fire has no event to send, so the run would start with an empty payload and a workflow that reads the event would find nothing there. Use a test run with a sample payload instead.

If you reach the endpoint another way, the same three refusals apply, each with a readable message: the workflow was never published, its trigger is event driven, or your monthly spend estimate has reached its cap.

Run now takes no input

There is no field to type into. A Run now fires with nothing attached.

If you need to hand the run something, that is a test run, which has both a note field and a custom payload field. The two are kept apart on purpose, and the next section is why.

A real run counts, a test run does not

This is the difference that matters most, and it is not about which button is prettier.

A learning workflow gets better because you accept its runs. Each accepted run becomes an example the platform learns the workflow's shape from, and a streak of them is the readiness signal that says the workflow is ready to codify.

• A Run now can be accepted. It counts toward that streak.
• A test run can never be accepted. Try and you get told plainly: test runs are scratch and never become examples.

That holds even when the test run executes the published SOP rather than a draft. A test is a test. The reason is that a test run can carry a payload you typed, with your authority behind it, so it is not evidence of the workflow working on real input.

A run that decides to do nothing is still a run

If a workflow's own instructions say it should only act inside a window, and you fire it outside that window, expect a run that starts, finds nothing to do, and finishes. Nothing is suppressed on your behalf. A real manual fire gets no special treatment, so what you see in the run log is what a real trigger would have produced at that moment.

A test run is where you steer that instead. Its note field exists for exactly this: "assume it is the 10am fire".