Workspace vs Project Scope
1 min read
Custom fields have two levels in Hawzu: workspace definitions and project configuration.
Understanding the difference prevents accidental global changes and helps projects stay flexible.
Workspace Fields Define The Field
Section titled “Workspace Fields Define The Field”Workspace fields define the shared field itself.
At the workspace level, users can manage:
- Name
- Description
- Field type
- Workspace status
Workspace fields can be reused by projects, but they do not automatically appear on project work items.
Project Fields Configure The Field
Section titled “Project Fields Configure The Field”Project fields decide how a field behaves in one project.
At the project level, users can configure:
- Whether the field is enabled.
- Which views use the field.
- Whether the field is required.
- Whether the field has a default value.
- Dropdown options for that project configuration.
Project configuration lets the same field be important in one project and hidden in another.
Workspace Scope In The Project Table
Section titled “Workspace Scope In The Project Table”In a project, fields with Workspace scope come from the workspace field catalog.
Project users can configure how these fields behave locally, but they do not change the workspace definition.
For example, a project may enable Environment for defects only, while another project may enable the same field for test cases and releases.
Project Scope In The Project Table
Section titled “Project Scope In The Project Table”Fields with Project scope are created for the current project.
They are useful for project-specific needs that should not become part of the shared workspace catalog.
Project-scoped fields can be removed or deprecated within that project according to usage.
What Can Be Edited Where
Section titled “What Can Be Edited Where”Workspace page:
- Edit active workspace field name and description.
- Remove unused workspace fields.
- Deprecate used workspace fields.
Project page:
- Enable new fields.
- Configure views, required behavior, defaults, and dropdown options.
- Disable fields locally.
- Remove unused project fields.
- Deprecate used project fields.
Practical Guidance
Section titled “Practical Guidance”Use workspace fields for shared language. Use project fields for local needs.
If multiple projects ask for the same project field, consider creating a workspace field instead.
Next Steps
Section titled “Next Steps”- Create fields in Create Custom Fields
- Review statuses in Field Lifecycle
- See supported views in Where Custom Fields Appear