Tests

Test a Draft Workflow as a real execution, with explicit awareness of external side effects and test-mode differences.

Tests let builders turn expected Workflow behaviour into repeatable checks against the current Draft.

The Workflow header calls this tab Test; the panel it opens is currently headed Evaluations. They are the same Workflow-testing surface.

Creating a Workflow test by selecting variables and writing plain-language evaluation criteria.

A test is attached to an action's output. Create it from the flask control beside a variable in the run output, choose the variables to evaluate, describe the criteria in plain language, and use the evaluation configuration to control how the criteria are judged.

A saved Workflow test with a passing result and the current result filters and Run all control.

Tests are real executions

Running a test does not replay the whole Workflow from a static recording. The trigger, user-interface steps and operator-action steps are replayed from the captured fixture; other actions on the tested path execute again for real.

That means a test can skip the human form while still sending the email, writing to the ERP, running code or making another connected-system change.

Use safe fixtures, test records or non-destructive inputs where appropriate.

What a test should establish

A useful test makes clear:

• the input or scenario being exercised;

• the result or condition that should hold;

• which parts are deterministic enough to check repeatedly;

• what still requires a builder to inspect the external business outcome.

Tests are strongest when they capture a meaningful operational expectation rather than only checking that the Workflow returned some output.

Tests do not replace runtime evidence

Passing tests reduce uncertainty about known scenarios. They do not prove that every live input, provider response or external-system condition will behave the same way.

Use Run for interactive draft iteration, Test / Evaluations for repeatable expectations, and Monitoring for evidence from actual executions over time.

Publishing is a separate step. A successful test does not itself move the Draft onto the live path.