Sample payloads and test runs

An event-driven workflow has a problem the moment you build it: you cannot see it work until the event happens, and the event happens on somebody else's schedule. Sample payloads solve that.

Where the samples come from

Right after the interview sets an event trigger, it drafts around three realistic sample payloads for that event, taken from the service's own documentation and from what your SOP says the work involves. They appear in the workspace under Trigger test payloads, on a tab called Generated. The first one is pinned automatically, so you can test immediately.

The other tab, Past, fills up once the workflow has run for real. It lists payloads from recent runs that were started by a schedule or a webhook, one per run. Click one and it is copied into your library and pinned in the same action, so a pinned payload is always something durable and never a pointer at a run that could be cleaned up later.

A workflow with no event trigger says so instead of showing an empty list: it runs on demand or on a schedule, so no payload is required.

Capturing a real delivery

A workflow triggered by a webhook URL can do better than a drafted sample. It can catch the real thing before it goes live.

Open a listen window and the URL accepts one delivery for two minutes, although the workflow is still a draft and answers a 404 to everything else. Go to the other system and make the event happen for real. What lands is copied into the payload library and pinned in the same action, so the next test run fires with the body the service actually sends rather than the one the assistant expected it to.

Two places to do it, and they open the same window:

• In the interview. Ask the assistant to listen. The capture comes back into the thread as data, so it can read the payload and ask you about the parts of it that are ambiguous.
• In the console. The test run panel offers listen, then run a test, which opens the window and then fires a test run against what it caught.

One window catches one delivery and closes on it. If nothing arrives inside the two minutes, nothing is captured, and you open another one. Regenerating the URL closes an open window too, because a listen armed against the old URL would otherwise be consumed by the first delivery to the new one.

Publishing ends all of this. A delivery to a live workflow is a run, and its payload appears in the Past tab like any other.

Pinning decides what a test run sends

Exactly one payload is pinned at a time, marked with a pinned chip. That is the one a test run fires with. Click any other row to move the pin.

Test run

The Test run button sits in the workspace header and fires straight away. It uses whichever SOP you are currently looking at:

• Looking at the published workflow, you get a test run of that.
• Looking at an open interview draft, you get a test run of the draft, and the toast names the snapshot it pinned, for example "Queued a draft test run (v1.2)". That snapshot is frozen at the moment you clicked, so the run stays reproducible even if the draft moves on.

Adding a note or a custom payload

Under the payload library there is a disclosure labelled Add a note or custom payload, with two fields:

• Note to the agent. Free text, delivered as context for this fire. Its own placeholder shows the intended use: "assume it is the 10am fire". This is how you exercise a time-dependent path without waiting for the clock.
• Custom payload (JSON object). Merged into the test payload as data.

Both are submitted with the Run test button inside that panel. The Test run button in the header ignores them and always fires as-is, so if you filled the fields in, use the button next to them.

What a test run refuses to do

The point of a test run is that it proves something. So it declines rather than improvises:

• An event-driven workflow with no pinned payload is refused. The platform will not invent an event, because a run on a made-up payload proves nothing. Pin a sample and try again.
• A custom payload that collides with the pinned sample is refused, with the colliding key named. Merging one over the other would hand the run a payload the service never sent.
• An empty SOP is refused. There is nothing to run yet.
• A draft run with no open interview is refused. There is no draft.
• A test run over your spend cap is refused, because a test spends real money on a real model.

Every one of these answers the click immediately, before anything is queued.

Testing a scheduled workflow

A scheduled workflow needs no pinned payload, but a test run of one still carries a fired_at value, because a live scheduled run always has one and a step may select it. The platform synthesises the current time for the test.

If you want a different instant, put your own fired_at in the custom payload field and the platform leaves it alone. That is how you test the end of the month without waiting for it.