Every team requests custom fields. Most requests come from “I want to track X.” Half should be denied. The remaining half need careful design or they become orphan dropdowns nobody uses.
The four-question gate
Before adding any custom field, answer:
- What decision will this data drive? (No decision = no field.)
- Who fills it in and when? (No clear owner = no field.)
- What happens if it is empty? (No defined behavior = no field.)
- How long do we keep it? (No retention plan = no field.)
If three of four answers are weak, deny. The team will adapt.
Field types and their costs
Each field type has a cost:
- Text: cheap to create, expensive to report on (free text is unsearchable).
- Dropdown: cheap to maintain if option list is fixed; expensive if option list grows quarterly.
- Checkbox: cheapest, hardest to filter on (true/false has limited expressiveness).
- Date: useful for SLA, expensive when timezone unclear.
- Lookup: useful for relationships, expensive in render performance.
- Multi-select: powerful, terrible to report on (each option needs its own column).
Default to dropdown when in doubt. Specify the option list and a “decommission criteria” for each option.
Field placement
Where the field appears matters:
- Visible on creation: requester sees and fills (or defaults).
- Visible on agent screen: agents fill during work.
- Hidden, set by workflow: workflow writes, agents and requesters never see.
- Visible on portal: requester sees on submission and follow-up.
Place fields where they get filled. A field hidden from the agent screen but required at close fails 100 percent of the time.
Validation
Required fields must be required at the right step:
- Required at creation: must be filled to submit.
- Required at status change: must be filled to move to the next status.
- Required on close: must be filled to close.
Common pattern: resolution code required to close. Without it, agents close tickets with no root cause data, killing trend analysis.
Default values
Setting a default reduces empty fields but creates noise if the default is “Unknown.” Default only when one value is overwhelmingly common (90 percent or more). Otherwise leave blank and require fill.
Renaming and deleting
Renaming a field changes the label everywhere; existing data stays. Safe.
Deleting a field is permanent and orphans all historical data. Never delete without:
- Exporting all values for audit.
- Confirming no active workflows reference the field.
- Confirming no reports reference the field.
When in doubt, mark inactive (hide from forms but keep data) instead of delete.
Lookup fields and load time
Lookup fields slow down record load. Each lookup is a separate query. A ticket with five lookups runs five queries on every page view.
Cap visible lookups per record at three. Push others into custom tabs (lazy-loaded) or related records (separate page).
Reporting on custom fields
Most custom fields show up in reports as filter options. Multi-select and free text do not (or do badly). Plan reporting before approving the field type.
Field ownership
Each field has a business owner. When the owner leaves, the field needs reassignment. Without ownership, fields linger past their usefulness because nobody dares retire them.
What to do this week
Pull your custom field list. Count fields where the field name does not clearly indicate purpose. For each, find the owner and ask: “What decision does this drive?” Retire fields with no clear answer.
