Skip to content
Hawzu Docs

Custom Fields Overview

2 min read

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:

  • Workspace fields define reusable field definitions.
  • Project fields decide how those fields behave in a project.

This keeps the workspace vocabulary consistent while letting each project decide what to show, require, or retire.

Workspace Fields

Section titled “Workspace Fields”

Workspace fields are shared definitions.

They define:

  • Field name
  • Description
  • Field type
  • Workspace-level status

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

Section titled “Project Fields”

Project fields are the project-level configuration for custom fields.

In a project, teams can:

  • Enable a workspace field.
  • Create a project-specific field.
  • Choose where the field appears.
  • Mark the field required or optional.
  • Set a default value.
  • Configure dropdown options.
  • Disable, remove, or deprecate fields in that project.

The project fields table shows columns such as Name, Description, Type, Scope, Status, Views, Is Required, Has Default Value, Created On, and Actions.

Supported Field Types

Section titled “Supported Field Types”

Hawzu supports:

  • Number
  • Text Box
  • Text Area
  • Checkbox
  • Dropdown
  • Date Picker
  • Link

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.

Supported Views

Section titled “Supported Views”

Project fields can be shown in:

  • Testcase
  • Requirement
  • Release
  • Defect

Each project can choose different views for the same workspace field.

Field Statuses

Section titled “Field Statuses”

Workspace fields can be:

  • Enabled
  • Deprecated

Project fields can be:

  • New
  • Enabled
  • Disabled
  • Deprecated
  • Deprecated at workspace

These statuses help teams introduce fields gradually, pause fields locally, and retire fields without losing historical values.

Permissions

Section titled “Permissions”

Available actions depend on the user’s workspace or project access.

Users may need permission to:

  • Create custom fields.
  • Edit custom fields.
  • Remove or deprecate custom fields.

If an action is unavailable, review the user’s workspace or project role.

Next Steps

Section titled “Next Steps”