Custom fields let teams capture structured information that is specific to their workflow. They can appear on test cases, requirements, releases, and defects.
Hawzu uses a two-level model:
This keeps the workspace vocabulary consistent while letting each project decide what to show, require, or retire.
Workspace fields are shared definitions.
They define:
Workspace fields do not automatically appear on project work items. A project must enable and configure the field before users see it in project forms.
The workspace fields table shows columns such as Name, Description, Type, Status, Used In, and Created On.
Project fields are the project-level configuration for custom fields.
In a project, teams can:
The project fields table shows columns such as Name, Description, Type, Scope, Status, Views, Is Required, Has Default Value, Created On, and Actions.
Hawzu supports:
Field type is locked after creation. If the wrong type is selected, create a replacement field with the correct type and retire the old one.
Project fields can be shown in:
Each project can choose different views for the same workspace field.
Workspace fields can be:
Project fields can be:
These statuses help teams introduce fields gradually, pause fields locally, and retire fields without losing historical values.
Available actions depend on the user’s workspace or project access.
Users may need permission to:
If an action is unavailable, review the user’s workspace or project role.