Custom Fields and Metadata
Metadata that drives decisions
Custom fields attach structured data to tasks so you can filter, sort, and report consistently. Field types include text, number, drop-down (single- and multi-select), date, people, and checkbox. Fields are defined at the workspace (org) library level and added to projects, which means a field can be reused across projects for comparable reporting. Drop-down options are managed centrally; editing an option updates it everywhere it's used.
Design principles
Keep the field set small and purposeful. Prefer drop-downs over free text when values must be consistent, because free text breaks filtering and grouping. Use number fields for anything you'll sum or average. Remember that fields added to a project become available on tasks in that project; tasks in other projects won't show them unless the field is also added there.
Traps in questions
A classic trap is assuming a field value follows a task when it's moved to a project that doesn't have that field - it doesn't display, and the data can appear lost. Another is confusing field-level permissions (who can edit a field) with project permissions. Also watch for questions implying multi-select and single-select are interchangeable; multi-select can't be used the same way for single-value grouping.
Rule of thumb
If you'd ever want to group, filter, chart, or sum by it, it should be a custom field, not text buried in the task description. If only one project needs it, still consider the workspace library so future projects can reuse it.