Custom Fields Best Practices

2 min read

Custom fields are powerful because they shape how teams capture data. A small amount of governance keeps them useful instead of noisy.

Start At The Workspace Level

Use workspace fields for shared concepts that multiple projects may need.

Good workspace fields describe reusable ideas:

Environment
Customer Tier
Browser
Risk Level

Avoid creating workspace fields for one-off project needs.

Use Project Configuration For Enforcement

Do not make every useful field required.

Project teams should decide:

Where the field appears.
Whether the field is required.
Whether a default value helps.
Whether the field should be enabled, disabled, or retired.

This keeps workspace definitions consistent without forcing every project into the same workflow.

Name Fields Clearly

Use names that describe the value users should enter.

Prefer:

Test Environment
Customer Tier
Release Risk

Avoid:

Env
Type2
Misc

Descriptions should explain when the field should be used.

Choose Field Type Carefully

Field type cannot be changed after creation.

Use:

Dropdown for controlled reporting values.
Text Box for short free-form values.
Text Area for longer notes.
Number for numeric comparisons.
Checkbox only for clear yes/no meaning.
Date Picker for calendar dates.
Link for URLs.

If the field type is wrong, create a replacement and retire the old field.

Keep Dropdowns Focused

Dropdown fields work best when options are clear and limited.

Good dropdowns:

Use stable option names.
Keep colors meaningful.
Avoid duplicate or near-duplicate options.
Use a default only when it is usually correct.

Changing dropdown options often can confuse reporting and users.

Be Careful With Required Fields

Required fields improve data quality only when users can reliably provide the value.

Before making a field required, confirm:

The field is needed in that view.
A default value is suitable, or users know the answer.
Existing items can be updated safely.

Use the impact summary to understand where defaults will be applied.

Retire Fields Safely

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.

Review Regularly

Periodically review:

Fields with unclear names.
Fields not used by projects.
Required fields that slow users down.
Dropdown options that are no longer useful.
Deprecated fields that can now be removed.