Tests: make a flow prove itself before it's published

Schedules, triggers, share links and MCP all run a flow's published version. Tests stop an edit — a prompt tweak, a new model, a changed threshold — from going live and quietly making the output worse.

Add tests

Open a saved flow in the Builder and press Tests.

• Add an item from the current run turns an item you're happy with into a test case: its inputs (text, images, files) are copied, with a first check that the result isn't empty. Or start a Blank case and type the inputs.
• Give each case one or more checks. A check looks at the final Result or at any named step, and asks: contains, doesn't contain, is exactly, matches pattern, number ≥ / ≤ (the first number in the text — handy for a QA score), isn't empty (works on image steps too).
• AI judge: write a short rubric ("a concise title that names the product and its size") and a pass mark. A cheap Claude model scores the output 0–100 — about a tenth of a cent per check. It needs a Claude key in a pool.

Run tests

Run tests runs the flow's last saved version for real, on your keys, with the test cases as its items (the Tests button saves your draft first). Spend limits apply. Results show each check passed or failed and what actually came back. A step with no key runs in test mode and the results say so — give it a key for a real test.

Tests refuse flows that would act outside FlowArray or wait for a person when run: a Send to a URL step, a Call a tool step, an agent allowed to change things, or an Approve card.

Publishing with tests

Once a flow has tests, Publish works only when they passed on exactly this version. Moving cards around doesn't count as a change; editing a prompt, a model or a setting does, and the tests need to run again.

If you're an admin and publishing anyway is the right call, the Publish dialog lets you, with a written reason. The reason is recorded in Settings → Activity. A flow without tests publishes exactly as before.