Workflow Settings

Each workflow context has its own Settings panel, accessible via the Settings button at the top of the Workflows page. Settings are context-specific — the Repository context configures which states populate new runs, while the Runs and Sessions contexts configure automation rules that trigger state transitions at key moments.

Opening settings

1. Go to Admin → Workflows.
2. Select the context tab whose settings you want to configure: Repository, Runs, or Sessions.
3. Click the Settings button in the top-right area of the panel.
4. Make your changes and click Save.

Settings are stored per context. Changing Repository settings has no effect on Runs or Sessions settings, and vice versa.

Repository settings — Include in Runs

When a new test run is created, it can be seeded with test cases that are currently in specific workflow states. The Repository settings let you choose which states are included in that initial selection.

How Include in Runs works

The settings modal shows a checkbox list of all your Repository states, each displayed with its icon and colour. Check the states whose test cases should be pulled into new runs by default.

• Multiple states can be selected simultaneously.
• States marked with a (Disabled) tag are currently inactive. They can still be included in runs settings for future use, but disabled states will not match any test cases until they are re-enabled.
• If no states are selected, new runs will not automatically include any test cases based on workflow state.

Example

Suppose your Repository states are: Active, Draft, Deprecated, and Blocked. You configure Include in Runs to include Active and Blocked. When a team member creates a new run, it will by default be seeded with test cases that are currently in the Active or Blocked state — Draft and Deprecated test cases are excluded.

Runs settings — Automation rules

The Runs context has two fixed automation rules. These rules define which state a run should automatically transition to when a specific event occurs.

Automation rule execution is coming in a future release. Rules can be configured now and will take effect when automated state transitions are supported in the Runs module. Saving rules today ensures they are ready to activate when the feature ships.

The two Runs rules

When the first result is added to a run

Fires the first time any test result is recorded against the run. Use this to automatically move a run from a "Planned" state to an "In Progress" state as soon as execution begins — without requiring manual intervention.

When a run is closed

Fires when the run is explicitly closed. Use this to automatically transition the run to a terminal state like "Closed" or "Complete" when work is done.

Configuring each rule

For each rule you can:

• Enable or disable the rule — use the toggle to turn the rule on or off without losing its configuration.
• Select a target state — choose the state the run should move to when the rule fires. Only enabled Runs states appear in the dropdown. If you disable a state that is currently selected as a target, the rule will still be saved but the target will need to be updated before the rule can execute.

Both rules always exist — they cannot be added or removed. If you do not want a rule to have any effect, leave it disabled.

Sessions settings — Automation rules

The Sessions context has the same two-rule structure as Runs, but applied to individual test sessions.

Automation rule execution is coming in a future release. Rules can be configured now and will take effect when automated state transitions are supported in the Sessions module.

The two Sessions rules

When the first result is added to a session

Fires the first time any result is recorded in the session. Use this to automatically move a session from "Open" to "Active" the moment a tester starts working.

When a session is closed

Fires when the session is explicitly closed. Use this to automatically transition the session to a "Completed" or "Signed Off" state at the end of testing.

Configuring each rule

Configuration works identically to Runs rules: enable or disable each rule with a toggle, and select a target state from the dropdown of enabled Sessions states. Both rules always exist and cannot be added or removed.

Settings summary