#Custom Fields Overview
Custom Fields allow teams to extend Hawzu with additional metadata tailored to their workflow. They help capture information that doesn’t fit into standard fields while maintaining consistency, validation, and auditability across the workspace.
Hawzu follows a governing → enforcing model for custom fields, giving teams both structure and flexibility.
#Core Concepts
#Workspace Custom Fields (Governing)
Workspace-level custom fields define what fields exist across the workspace.
At the workspace level:
- Fields act as a shared catalog
- Fields define name, description, and data type
- Fields are not enforced automatically
- No validation rules are applied globally
Workspace fields ensure consistency and reuse, but do not force behavior on projects.
Workspace fields define what is possible, not what is required.
#Project-Level Field Usage (Enforcing)
Projects decide how workspace fields are actually used.
At the project level, you can:
- Enable or disable workspace fields
- Mark fields as required or optional
- Control where fields apply:
- Test cases
- Releases
- Defects
- Requirements
- Enforce validation rules locally
This allows:
- Different projects to enforce the same field differently
- Fields to exist globally but be unused in specific projects
- Gradual adoption without breaking workflows
Workspace fields define structure.
Projects define enforcement.
#Field Type Immutability
Once a custom field is created, its field type cannot be changed.
This is a deliberate system guarantee to ensure:
- Data integrity
- Stable analytics and reporting
- Predictable validation behavior
- Reliable historical records
For example:
- A Dropdown field cannot be converted to Text
- A Number field cannot become a Date
Changing field types after data exists can corrupt history and analytics. Hawzu prevents this by design.
If requirements change, the recommended approach is to:
- Create a new field with the correct type
- Migrate usage gradually
- Deprecate the old field
#Field Lifecycle Management
Hawzu provides clear lifecycle controls to manage fields safely.
#Deprecating a Field (Recommended)
Deprecation is a safe, non-destructive action.
When a field is deprecated:
- Existing data remains untouched
- The field is hidden from creation forms
- The field cannot be used for new entries
- Historical records continue to display the field value
Use deprecation when:
- A field is no longer needed going forward
- You are transitioning to a replacement field
- You want to preserve audit history
Deprecation allows evolution without data loss.
#Removing a Field (Use with Caution)
Removing a field is a destructive operation.
When a field is removed:
- The field definition is deleted
- All associated values are permanently removed
- Historical data referencing the field is lost
Removal should only be used when:
- The field was created by mistake
- No meaningful data exists
- You are certain it is not referenced anywhere
Hawzu strongly recommends deprecating fields instead of removing them whenever possible.
#Enabling and Disabling Fields
Field availability follows a layered model.
#Workspace Level
- Fields can exist but remain unused
- No enforcement or validation occurs
- Fields act as available building blocks
#Project Level
- Fields must be explicitly enabled
- Validation rules apply only within the project
- Required/optional behavior is enforced locally
This ensures:
- Maximum flexibility across teams
- No accidental global enforcement
- Clear ownership of validation rules
#Supported Field Types
Hawzu supports multiple field types, including:
- Number
- Text Box
- Text Area
- Checkbox
- Dropdown
- Date Picker
- Link
Field type selection is permanent once created.
Dropdown fields additionally support:
- Custom option labels
- Icons per option
- Color-coded values
- Default selections
#Design Philosophy
Structure without rigidity.
Control without chaos.
Hawzu separates definition from enforcement so teams can scale workflows without breaking data or slowing delivery.
#Next Steps