#Custom Fields Best Practices
Custom Fields are powerful, but with great flexibility comes the need for discipline. This guide outlines best practices to help you design scalable, maintainable, and meaningful custom fields across your workspace and projects.
#Design Principles
#Start With Governance, Not Enforcement
- Define custom fields at the workspace level first
- Treat workspace fields as a shared vocabulary
- Avoid creating fields directly for short-lived or one-off needs
Workspace fields should represent business concepts, not implementation details.
#Keep Field Names Clear and Stable
- Use descriptive, unambiguous names
- Avoid abbreviations unless universally understood
- Prefer nouns over actions
Good examples
Test EnvironmentRelease RiskExecution Type
Avoid
#Choose the Right Field Type Early
- Field type cannot be changed after creation
- Think ahead about:
- Will this value grow?
- Does it need ordering?
- Should it be searchable or filterable?
Guideline
- Use Dropdowns for controlled values
- Use Text sparingly for free-form input
- Use Boolean only when binary makes sense
#Workspace-Level Best Practices
#Treat Workspace Fields as Contracts
Workspace fields act as contracts between teams and projects.
- Avoid frequent changes
- Communicate field intent clearly
- Document expected usage
Once created, assume fields will be reused long-term.
#Prefer Deprecation Over Removal
When a field is no longer needed:
- Deprecate the field instead of removing it
- Allow projects time to migrate
- Keep historical data intact
Deprecation is safe. Removal is destructive.
#Avoid Overloading Fields
Do not reuse one field for multiple meanings.
Bad
Category used for priority, type, and module
Good
- Separate fields for:
- Priority
- Test Type
- Module
Clarity beats convenience.
#Project-Level Best Practices
#Enable Only What You Need
Projects should:
- Enable only relevant workspace fields
- Disable unused fields to reduce noise
- Avoid exposing fields users don’t need
A smaller form improves data quality.
#Enforce Carefully
Use enforcement deliberately:
- Mark fields as required only when critical
- Avoid over-enforcement that slows users down
- Apply enforcement only where it makes sense
Example
- Required for Defects
- Optional for Test Cases
#Configure Per Context
A field doesn’t need to apply everywhere.
- Apply fields selectively:
- Test Cases
- Releases
- Requirements
- Defects
This keeps each workflow focused and intentional.
#Dropdown Field Best Practices
#Use Meaningful Options
- Keep dropdown options limited and intentional
- Avoid overly granular values
- Use colors and icons to improve scanability
Good
Avoid
#Avoid Reordering Frequently
Reordering dropdown values can:
- Confuse users
- Break reporting expectations
Only reorder when there is a strong reason.
#Change Management
#Communicate Changes Early
Before changing or deprecating fields:
- Inform affected teams
- Explain the reason
- Provide migration guidance
Custom fields affect workflows deeply — surprise changes cause friction.
#Review Periodically
Schedule periodic reviews:
- Remove unused fields
- Deprecate outdated ones
- Validate enforcement rules
Custom fields should evolve, but deliberately.
#Common Pitfalls to Avoid
- Creating fields for one-off needs
- Overusing required fields
- Using text fields where dropdowns fit better
- Removing fields with existing data
- Letting every project invent its own vocabulary
#Final Guidance
Think of custom fields as infrastructure, not configuration.
When designed well:
- Reporting becomes consistent
- Analytics become reliable
- Collaboration becomes easier
When designed poorly:
- Data fragments
- Forms become noisy
- Teams lose trust in the system
Design once. Govern centrally. Enforce locally.
#Next Steps