Custom Fields
Custom fields let a project track structured information that does not belong in the standard ticket fields. Use them for data your team reviews repeatedly, filters by, or requires before a workflow transition.
Examples include customer tier, region, product area, implementation phase, launch date, budget, reviewer, environment, or support channel.
Field Types
TOW supports these project custom-field types:
| Type | Use for |
|---|---|
| Short text | A brief value such as account ID, environment, or release name. |
| Paragraph | Longer notes that should still stay structured on the ticket. |
| Number | Budget, score, count, size, or numeric priority. |
| Date | A calendar date without time. |
| Datetime | A date and time, such as a review window or launch timestamp. |
| Single select | One option from a managed list. |
| Multi select | Multiple options from a managed list. |
| Checkboxes | Multiple checklist-style options. |
| User single | One workspace user. |
| User multi | Multiple workspace users. |
| Labels | Free-form labels managed as a custom field. |
Choose the narrowest type that supports the review process. For example, use single select for controlled reporting and short text only when values cannot be predicted.
Field Keys
Every custom field has a stable key. TOW uses the key in filters and TQL with the cf. prefix, such as cf.customer_tier.
Good keys:
- Start with a letter.
- Use lowercase letters, numbers, and underscores.
- Stay stable after teams begin filtering on them.
- Describe the field without project-specific slang.
Changing names is safer than changing keys. The name is what people read; the key is what saved filters and workflow rules depend on.
Options
Select, multi-select, and checkbox fields use managed options. Each option has a label and a stable option key.
Use options when reporting should be consistent. For example, enterprise, mid_market, and startup are easier to filter than free-text customer segments.
Archive options that should no longer be used. This preserves older values while keeping active tickets focused on the current option set.
Lifecycle
A healthy custom-field lifecycle has five steps:
- Define the reporting or workflow need.
- Create the field with a stable key and clear name.
- Add it to ticket forms, board cards, or saved filters where people will use it.
- Use it in workflow required-field rules only when the value is truly needed.
- Archive the field when it is no longer maintained.
Avoid fields that no one owns. A custom field that is not updated will make filters and reports less trustworthy.
Archive and Restore Fields
Archiving a field removes it from active use while preserving project history. Restore a field if it becomes relevant again.
Archive a field when:
- The team stopped maintaining it.
- The process changed.
- A better field replaced it.
- The field was created for a temporary initiative.
Before archiving, check saved boards, TQL filters, workflow required fields, and card layouts that reference the field.
Use Custom Fields in TQL
Custom fields use cf.<key> in TQL:
project = APP AND cf.customer_tier = enterprise
Custom-field filters require a single project scope because each project defines its own fields. Add a project = KEY clause or run the query inside a project-scoped view.
Different field types support different operators. Text fields support text contains, number and date fields support ranges, and select/user fields support equality and set membership.
Use Custom Fields in Workflows
Project workflows can require custom fields before a ticket moves through a transition. For example, a customer support project might require cf.customer_tier before moving a ticket to resolved.
Use required custom fields only at the moment the value is genuinely needed. Requiring too much information too early slows execution and creates low-quality data.
Use Custom Fields on Boards
Custom fields can appear on saved board cards and in card layouts. This is useful when a board review depends on fields such as customer, region, due date, reviewer, or severity.
Show only the fields people need for the board's purpose. A triage board and an executive review board usually need different card layouts.
Custom fields belong to a project. When a ticket moves to another project, TOW clears its project custom-field values because the target project may define different fields or options.
After moving a ticket, fill in the target project's required custom fields before moving it through restricted workflow transitions.