Status Properties
Every status has a fixed set of fields that control how it is identified, displayed, and interpreted. This page describes each property and how it affects behaviour across the platform.
Identity fields
System name
A unique, permanent identifier for the status. It may contain lowercase letters, numbers and underscores, and must start with a letter (e.g. passed, blocked_by_env). The editor fills it in from the name as you type — capitals are lowered, anything else becomes an underscore, and a value that would not start with a letter is prefixed s_. You can edit it before the first save; afterwards the field is locked and reads “Fixed after creation — integrations depend on it.”
Choose the system name carefully. It is permanent, and it is what integrations, reports and API consumers refer to. If you need a different identifier, you must create a new status.
Name
The label shown to users across the platform. It can be updated at any time without affecting the system name or historical data.
Aliases
Optional alternative names, entered comma-separated. Aliases are accepted by the API and by automation when a result arrives under a different word for the same outcome, and the Statuses list searches them alongside the name and system name.
Visual properties
Icon and colour
One control in the editor’s Identity panel sets both the icon and the colour used to represent the status throughout the UI — in result lists, charts and badges. Appears as, beside the name, previews the result as you change either one. Pick something that reads at a glance: green for a pass, red for a failure.
Outcome
Outcome is what the platform uses to decide whether a result passed. It is one choice of three, not a set of independent flags, so the contradictory combination cannot be expressed:
| Outcome | What it means |
|---|---|
| Success | Counts as passed. Results with this status count toward the success total in summaries and reports. |
| Failure | Counts as failed. Typically used for failed, errored or blocked statuses. |
| Neutral | Neither. The result is recorded but counts toward neither total. |
Everything that asks “did this pass?” — pass rates, the run-health card, requirement coverage, the release gate — reads this property, never the status name. A status your team called Passed w/ exceptions counts as green because of its outcome, not its wording.
Counts as a completed result
A separate switch, directly under Outcome in the Meaning panel: “Progress bars treat a case with this status as done.” It is independent of the outcome, so a Passed with warnings status can be both Success and completed, and a Skipped status can be Neutral and still count as done.
Display order
Statuses are offered in display order, then alphabetically by name where two share the same order. There is no control for it in the editor — every status created here is saved with the same default order, so new statuses sort by name among themselves.
System and protected statuses
Some statuses are built into the platform and are marked as system statuses — the Statuses list shows a System badge on their rows. System statuses cannot be deleted, though they can be disabled. They provide a stable baseline that the platform relies on for core functionality.
The Untested status carries a Protected badge instead. It is the state every case starts a run in — every result is Untested until an outcome is recorded — so it has protections beyond the system-status rules. Opening it shows one banner at the top of the editor saying exactly which fields are open and why; the locked controls stay on screen and repeat the reason on hover.
- Cannot be disabled or deleted — both menu items are greyed out.
- Meaning is locked — the outcome and the completed switch cannot be changed.
- Availability is locked — Untested stays available everywhere.
- Project assignment is locked — Untested always applies to all projects.
- Can be customised — the name, aliases, icon and colour can still be updated.