Workflow Automation

Each workflow carries an automation panel underneath its state list, on the same page — so the states a rule points at are visible while you point it. What the panel offers depends on which workflow you are looking at.

There is no Settings button and no settings dialog. Scroll past the list and the panel is there. Changes save as you make them; there is nothing to submit.

Test case workflow — which cases a new run picks up

The panel is titled When a run is created and holds one setting, Include cases in these states: a multi-select of the workflow’s states, described as “Cases in any other state are left out of new runs by default.”

The setting reaches you through the run composer. Open the composer for a new run and every case in the project whose workflow state is in this set arrives already ticked, above a band that reads “N cases included by the Test case workflow — add or remove any”. That is the whole promise: the ticks are a starting point, not a verdict. Tick another case or untick a seeded one and the band goes back to counting ticks — “A frozen snapshot of the N ticked cases” — and the run is created from whatever is ticked when you press Create run.

• An empty set seeds nothing. The composer opens with no ticks and the ordinary prompt, “Tick the cases you want in the list below.” An unset preference starts you from an empty list, not from every case.
• Only new runs are seeded. Edit cases… on an existing run opens the composer against that run’s membership. Changing this setting never rewrites a run that already exists.
• A change here lands on the next composer you open — no reload, no sign-out.
• Cases outside the set are never barred. They are simply not pre-ticked; tick one and it joins the run like any other.

There is no “include all cases” button in the product. Run membership is always the tick list — see Creating a Run. The API and the MCP server do take an includeAllCases flag, and a caller that sends it gets this same set applied server-side: the run picks up only the project’s cases whose state is in it. One difference worth knowing on that path — an empty set there means “no filter”, so the run picks up every case, which is the opposite of what an empty set does in the composer.

Test run and exploration workflows — the rules

These two workflows each get a panel titled Automation holding two fixed rules. The set is fixed: rules cannot be added, removed or reordered — there are two, and those two are always there.

Each rule card carries the trigger, a switch, and a Change state to picker offering the enabled states of that workflow. Switching a rule off locks its picker with the reason The rule is off, and the row reads “This rule is off, so nothing changes state.” When the rule is on and has a target, it reads the consequence instead — “The run moves to In progress automatically.”

The four rules, and which of them take effect

All four rules are wired to the backend. Three of them are reachable from the product: recording a run’s first result, closing a run, and recording an exploration’s first result each move the record. The fourth — When session is closed — has no trigger in the exploration UI today; see its row.

A rule’s target state is protected

While a rule points at a state — on or off — that state cannot be disabled or deleted. Both menu items grey out with the reason An automation rule moves records to this state. Point the rule at a different state first. The test case workflow has no rules, so this never applies there.

Only enabled states can be targeted

The Change state to picker offers the workflow’s enabled states only. Because a targeted state cannot be disabled, a rule cannot end up aimed at a state nobody can use.

What automation does not do

• It does not move test cases. The test case workflow has no rules — a case’s state is set by hand, or starts at the workflow default.
• It does not fire twice. A rule fires on its trigger and later triggers of the same kind pass it by — the second, third and tenth result leave the state alone, wherever you have since moved it to.
• It does not run in reverse on its own. There is one deliberate exception, and it is not a rule: reopening a closed run moves it off the close rule’s target state — to the first-result target when the run has results, otherwise to the workflow’s default. It has to, or the reopened run would still be sitting in the state the product reads as “closed”.

The close rules run one way only. Closing a run moves it to the rule’s target state. The reverse does not hold: putting a run into that state is a relabelling, not a closing. If When run is closed points at Complete, picking Complete on a run’s About card marks it Complete and leaves it open — only Close run closes, with its guard and its sign-off snapshot. The same holds for explorations, where the point is moot in the UI anyway: an exploration’s workflow state is not editable there at all, and the State row on its Details card shows the session’s own Planned / Live / Debriefed progression, which is a different thing.

Summary