Custom fields are powerful because they shape how teams capture data. A small amount of governance keeps them useful instead of noisy.
Use workspace fields for shared concepts that multiple projects may need.
Good workspace fields describe reusable ideas:
Avoid creating workspace fields for one-off project needs.
Do not make every useful field required.
Project teams should decide:
This keeps workspace definitions consistent without forcing every project into the same workflow.
Use names that describe the value users should enter.
Prefer:
Test EnvironmentCustomer TierRelease RiskAvoid:
EnvType2MiscDescriptions should explain when the field should be used.
Field type cannot be changed after creation.
Use:
If the field type is wrong, create a replacement and retire the old field.
Dropdown fields work best when options are clear and limited.
Good dropdowns:
Changing dropdown options often can confuse reporting and users.
Required fields improve data quality only when users can reliably provide the value.
Before making a field required, confirm:
Use the impact summary to understand where defaults will be applied.
Prefer deprecation when a field has existing usage.
Deprecation keeps historical values visible while preventing new use. Removing is best for fields created by mistake or fields with no meaningful data.
Periodically review: