Status Master
The Status Master lets you configure the status labels that records can carry — the named states such as "Available", "Booked", or "Registered" that appear on a unit, stock, project, or subproject. You control the label text, its colour, and whether it is active, all scoped to your organization.
Where to find it: Masters → Status.
:::caution Labels vs. lifecycles — read this first The Status Master controls the labels you can configure. It does not change the fixed, system-defined lifecycle rules — which statuses are allowed to follow which, and what each system status means for booking, visibility, and customer view. Those lifecycle rules are built into the product and documented separately at Status Lifecycles. Think of the Status Master as naming and styling the boxes; the lifecycle defines how records move between them. :::
Status types (entity families)
Every status you configure belongs to exactly one status type, which says what kind of record the status applies to:
| Status type | Applies to | Example labels |
|---|---|---|
| PROJECT | Projects | Planning, Active, Completed |
| SUB_PROJECT | Subprojects | Draft, Launched, Closed |
| UNIT | Units | Available, Blocked, Booked, Registered |
| STOCK | Stocks | Wishlist, In Negotiation, Registered, Sold |
The same label text can be reused across different types — you may have a "Booked" under UNIT and a separate "Booked" under PROJECT — but a label must be unique within a single type (case-insensitive). A duplicate "Booked" within UNIT is rejected; "Booked" in PROJECT is allowed.
What a status record holds
| Field | Required | Notes |
|---|---|---|
| Status Name | Yes | The label text. Unique within its status type. |
| Status Type | Yes | PROJECT, SUB_PROJECT, UNIT, or STOCK. Cannot be changed after creation. |
| Colour | Yes | A colour code used to render the status as a coloured badge in lists and detail pages. |
| Document Type | No | An optional link to a Document Type — used where a status implies a required document (for example, a "Registered" status tied to the registration deed). |
| Active | Yes | Whether the status can be selected for new transitions. |
| Description | No | Free text explaining when to use the status. |
:::note Status type is fixed You cannot move a status from one type to another after it is created. If you configured a label under the wrong type, deactivate it and create a new one under the correct type. :::
Managing statuses (CRUD)
Where to find it: Masters → Status.
- Add. Choose the status type, enter the name and colour, optionally link a document type and add a description, set Active, and Save.
- List / filter. The list can be filtered by status type and by active state, and searched by name.
- Edit. You can rename a status, change its colour, link/unlink a document type, edit the description, and toggle Active. You cannot change its status type.
- Deactivate. Setting a status Inactive removes it from the pickers used for new transitions, while existing records that already carry it are unaffected.
- Delete. Deletion is guarded. A status that is referenced by any project, subproject, unit, or stock cannot be deleted; the system blocks it with "This Status is in use and cannot be deleted. Set to Inactive instead." Unreferenced statuses are soft-deleted.
Configurable labels vs. fixed system statuses
This distinction matters enough to spell out with examples:
- What you configure here: the display label, its colour, and whether it is active/selectable. You could rename the unit label shown to customers, or give "Booked" a distinctive amber badge.
- What you cannot change here: the underlying lifecycle behaviour. The product defines, for instance, that a unit which is Booked is unavailable to customers, that Draft units are hidden, and which transitions are legal (you cannot jump a unit straight from Draft to Registered). Those rules live in the system and are described in Status Lifecycles.
In short: the Status Master is for naming and styling; the lifecycle reference is for behaviour and transition rules. When you add a new label, make sure it maps sensibly onto the lifecycle stage it represents.
:::tip Keep labels aligned to the lifecycle Before inventing a brand-new status label, check the Status Lifecycles reference to see which lifecycle stages exist for that entity. Adding a label that has no corresponding lifecycle stage will confuse your team, because the record's actual behaviour is driven by the lifecycle, not the label. :::
Related
- Status Lifecycles — the fixed, system-defined transition rules and meanings
- Document Types — the optional link target for status records
- Reference Data Overview