Settingsbeginner

Field types reference

Every custom field type, what it stores, when to use it, and the gotchas. Picking right the first time saves a lot of cleanup later.

5 min read

Field types reference

Six types cover almost every business data point. Picking right the first time matters because changing a field’s type later usually means deleting and recreating it — losing whatever data was already populated.

Text

Single-line free-text input. Use for short, distinct values that don’t fit a closed list.

  • Order numbers, account IDs, external system IDs — Anything with a fixed set of values (use Select instead)
  • Reference codes, tracking numbers — Long descriptions (use Textarea)
  • One-off identifiers — Numeric values you’ll calculate on (use Number)

Keep field labels specific. Account ID reads better than ID; External Order Number is clearer than just Order.

Textarea

Multi-line text for descriptions, notes, or longer free-form content.

  • Internal notes about the contact or case — Short identifiers (use Text)
  • Detailed escalation context — Anything you’ll filter or group by in analytics — long text doesn’t aggregate well
  • Acceptance criteria, business context — Structured data — break it into multiple fields instead

Number

Integer or decimal numeric input. Used when the value is something you’d ever average, sum, sort, or compare.

  • Contract value, monthly revenue — Phone numbers (use Text — phone numbers aren’t quantities)
  • Quantity, days outstanding, score — Reference codes that happen to be all-digits (use Text)
  • Anything you’ll chart or filter on numerically — Money values where the currency varies — split currency into a Select field beside the Number

Date

Date picker. Stores a calendar date.

  • Contract start / renewal dates — Timestamps with hour and minute precision (Atender stores this on system events automatically; rarely needed as a custom field)
  • Birthday, anniversary — “Last contacted at” — Atender already tracks this; don’t duplicate
  • Deadlines, milestones —

Select

Dropdown — single choice from a list of options you define.

  • Categories, tiers, types — anything with a fixed taxonomy — Open-ended answers (use Text)
  • Priority levels, regions, departments — Lists that grow constantly with new values — option management becomes painful past 30–40 options
  • Anything you’ll filter, group, or report on —

For multi-value choices (a contact in two regions), create separate Select fields per dimension or use a Checkbox per option. Atender’s Select stores a single value per field.

Select field gotchas

  • Option values vs. labels: the option’s stored value is a machine slug, not the display label. When using a Select field as a condition in an automation, you compare against the slug.
  • Renaming an option changes the label everywhere but preserves the underlying slug. Existing data on conversations / contacts continues to point at the same option.
  • Deleting an option with assigned data leaves orphaned references. Reassign data first.

Checkbox

Single boolean — true or false, on or off.

  • Flags: VIP, opt-in to marketing, beta tester — Anything that has more than two states (use Select)
  • Yes/no acknowledgements — Anything you might add a third option to later

A checkbox defaults to unchecked. There’s no “indeterminate” or “unset” state in the data model — once a contact / conversation / case exists, the field is either true or false.

When two field types feel close

  • “Is this from a fixed list of values?” — If yes, Select. If no, Text.
  • “Will I do math on this?” — If yes, Number. If no, Text.
  • “Could there be more than two states later?” — If yes, Select from the start. Checkbox is hard to widen.
  • “Is this longer than a sentence?” — If yes, Textarea.

See also

Tags

Reference
Back to Settings