Automated Tests gives you a repeatable check that your thunk still produces the right answers — while you are actively changing it, and after it has gone to production.

You mark some work items as test work items, write down what must be true of each one's output, and re-run them whenever you want. The platform grades the results and tells you what passed, what failed, and what it could not decide.

This is the counterpart to hands-on testing. Driving the workflow by hand tells you what it does; a test suite tells you whether it still does it after your next change. See Testing your thunk by hand for the hands-on half, and Building a test plan for how to choose what to test.

It works best for outputs with stable values: an extracted amount, a classification, a required field that must not be empty. It is a poor fit for values that legitimately change on their own — a live schedule, a conversation, the contents of an external web page — because the test will go stale rather than catch a regression.

Open Tests in the left nav. It has three tabs:

The Tests area is available to thunk owners and admins. Its controls replay real work, so access is deliberately narrow.

There are two ways.

Promote an existing work item. Open any work item, go to its Tests tab, and add an assertion. That converts it into a test work item: it moves into the Tests pane and out of the regular work items list. This is the common path — you have just watched a real item go through the workflow, you like the result, and you want it checked from now on.

Add one directly. In the Test Rows tab, use Add and fill in the input form. The item is marked as a test work item immediately, so it stays in the Tests pane even before you have written a single assertion.

You can also mark a work item as a test work item without any assertions, using the Test row toggle on its Tests tab. That is useful for an input you want executed under test settings — a smoke case — without grading its output.

A test work item is a normal work item in every other respect. It runs the same workflow, through the same steps, using the same tools.

An assertion is a statement that must be true of that work item's output. Assertions are per work item, not global — they describe what this input should produce.

There are two kinds, and a work item can freely mix them.

A rule is a condition built with the same picker you use to filter the work items grid: choose a property, an operator, and a value. It passes when the work item matches.

Rules are graded without an AI model. They are free, instant, and give the same answer every time. Prefer them whenever the expectation can be stated exactly:

If you can write it as a rule, write it as a rule.

Some expectations cannot be expressed as a condition on a field — they are about whether generated content is right. Write those in plain English, one per line, and they are graded by a single AI call against the work item's output:

These cost a model call per assertion and, like anything AI-graded, are judgment rather than arithmetic. Keep them specific: an assertion that says "the output is good" cannot be graded consistently by anything, including a person.

If the work item has already run, Suggest from this row drafts one assertion per non-system property from the values currently there. It is a fast way to seed a suite from a run you are happy with — but read what it produces before saving. It describes what the workflow did, which is only the same as what it should do if that run was actually correct.

Two different things can be re-run, and the difference matters.

Re-grade test assertions re-evaluates the assertions against the output the work items already hold. It does not re-run the workflow. Use it when you have changed the assertions themselves, or want to reprocess grading after fixing a badly worded one. It is quick and cheap.

Re-run replays the workflow: the work items are reset and executed again through their steps, and their assertions are graded automatically when each one finishes. This is the real regression test — it exercises your instructions, your tools, and your connections. It costs what a real run costs.

Both are available from the Test Rows tab (scoped to the work items currently in view, so a filter narrows the run) and from Test Results (across all test work items).

Each assertion grades to one of three outcomes:

Each graded assertion also shows the reasoning behind the verdict and links to the properties the grader relied on, so you can jump straight to the value in question.

Failures are visible without opening anything: a test work item's row is tinted in the grid, and the Tests column carries the summary.

A re-grade produces a downloadable CSV report covering the work items it evaluated, listed newest-first in the Test Results tab. Each report contains one row per test work item: its business property values, a per-item summary such as 2/3 passed, 1 failed, and the detail of every assertion with its verdict and explanation.

Reports are how you show coverage and pass rate to people who do not work in the product day to day, and how you compare one run against an earlier one.

The Test Settings tab controls how test work items execute. These settings are durable — they apply to every test run of this thunk, including re-running a single work item.

Test mode. Treat all rows as test rows broadens everything below to every work item, not just those carrying assertions. It exists for hands-on testing; turn it off when you are done.

Test run.

Test email. Controls what happens when a test work item sends email:

Ordinary work items are unaffected by the email policy unless test mode is on.

Email is handled by the setting above. For other side effects — a step that files a ticket, updates a CRM record, or writes to a shared drive — turn on Skip this step for test work items in that step's Workflow Options. The step is then passed over whenever the work item is a test work item, and the rest of the workflow runs normally. See Control when a step runs and proceeds.

Skipping is the right answer when the step's effect is external and you do not need it to produce anything. When a later step depends on what the skipped step returns, mock the tool output instead, so the workflow still receives a plausible value.

The suite above grades a workflow's output for a given input. Custom tools have their own, narrower test mechanism — cases that run one tool directly and assert on what it returns. Both use the same two kinds of assertion. See Testing your custom tools.