Skip to content

Managing Custom Fields

3 min read

Use the Custom Fields pages to review, configure, and retire fields safely.

Workspace and project pages look similar, but they have different responsibilities.


The workspace page manages shared field definitions.

Visible columns include:

  • Name
  • Description
  • Type
  • Status
  • Used In
  • Created On

The Used In column shows how many projects use a workspace field. Hovering the count shows project names when available.

Workspace fields can be opened in the details view. In workspace details, users can edit the name and description when the field is still active.


The project page manages how fields behave in one project.

Visible columns include:

  • Name
  • Description
  • Type
  • Scope
  • Status
  • Views
  • Is Required
  • Has Default Value
  • Created On
  • Actions

The Scope column shows whether the field came from the workspace or was created for the project.


Use search to find fields by name, description, or default value.

Filters include:

  • Type
  • Status
  • Creation Date

Project pages also include filters for:

  • Is Required?
  • Has Default Value?
  • Views
  • Scope

Sorting is available for created date, name, description, and type. Some columns can also be sorted directly from the table header.


Use column visibility to show or hide optional columns.

The Name column is always visible. Workspace and project pages remember their column preferences separately.


Open a field row to review its details.

The details view shows:

  • Name
  • Description
  • Field type
  • Field options, for enabled project fields
  • Views, for enabled project fields
  • Status actions
  • Remove actions where available

The field type is shown as a badge and cannot be changed after creation.


Workspace fields allow editing the name and description.

Project fields allow editing project configuration when enabled:

  • Required or optional behavior
  • Default value
  • Dropdown options
  • Views

Project fields inherited from the workspace keep their workspace name, description, and type. Project teams configure how the field behaves locally.

Select Save Changes to apply updates. Select Cancel to return to the previous values.


Project fields can be enabled or disabled.

  • New fields are available to enable in the project.
  • Enabled fields can appear in the selected views.
  • Disabled fields are hidden from normal entry but may remain visible where existing values need reference.

Use Enable Field to make a field available in the project. Use Disable Field to hide it without removing its project configuration.


Project field actions include Duplicate.

Duplicating creates a new field based on the selected field. If the field is required, has a default value, and is used in views, Hawzu shows an impact summary before duplication.


The Remove action behaves differently depending on scope and usage.

  • Unused workspace fields can be deleted from the workspace.
  • Used workspace fields are deprecated across the workspace.
  • Unused project fields can be removed from the project.
  • Used project fields are deprecated for that project.

Deprecation keeps existing values for reference and prevents the field from being used for new data going forward.


This is an advanced, behind-the-scenes behavior that Hawzu handles automatically. Most users do not need to act on it.

When a project field change requires existing items to receive a default value, Hawzu may apply the change in the background.

The details view can show:

  • Background backfill in progress
  • Background backfill failed

If a backfill fails, saving the field again can queue a retry.