> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qwoty.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Field types
> The three data types available for custom fields in Qwoty.
When you add a custom field to a manageable object, you pick a **Data Type**. Qwoty currently supports three types — chosen to cover the vast majority of CPQ use cases without complicating the data model.
## Available types
| Type | Icon | Use it for | Example values |
| ---------- | ---- | --------------------------------------------------------------------- | ---------------------------------------------------- |
| **Text** | `T` | Free-form strings, codes, descriptions, dropdowns implemented as text | `Premium`, `B2B`, `EUR-FRA`, `Long descriptive note` |
| **Number** | `#` | Quantities, scores, dimensions, anything numeric | `160`, `4.5`, `2026`, `99.99` |
| **Date** | `📅` | Dates, deadlines, anniversaries | `2026-04-25`, `29/04/2026` |
## Text
Use Text fields for any string value: a customer type label, a project code, a free-form note. Text covers a wide range of needs because Qwoty doesn't enforce a value list — your team enters whatever makes sense for your process.
**Common Text use cases:**
* A `Customer type` field with values like `Prospect`, `Key Account`, `Partner`
* A `Project code` referencing your internal project tracker
* A `Notes` field for sales-rep context
* An `External reference` matching your ERP
**What Text accepts:**
* Any string up to a generous length limit
* Special characters, accents, line breaks (use double quotes when importing via CSV)
* Empty values (unless **Mandatory** is enabled)
Qwoty doesn't currently offer a native dropdown / select / multi-select type. To restrict values to a fixed set, use Text and document the allowed values in your team's playbook — or rely on your CRM's enum field and sync it via [CRM mapping](/user-guide/data-model/reference/crm-mapping).
## Number
Use Number fields for any numerical value: counts, dimensions, prices, scores. The value is stored as a number — you can compute, sort, and filter on it.
**Common Number use cases:**
* A `Headcount` field (e.g., 160 attendees on an event quote)
* A `Hectares` field on a customer in agriculture
* A `Tier level` field for customer segmentation (1, 2, 3)
* A `Custom discount %` field
**What Number accepts:**
* Integers and decimals (use `.` as the decimal separator)
* Positive and negative values (where the field permits)
* Empty values (unless **Mandatory** is enabled)
**What Number does NOT accept:**
* Currency symbols (`€`, `$`)
* Thousands separators (`1,234.56` is rejected — use `1234.56`)
* Text mixed with numbers (`160 attendees` is rejected — use `160` and put `attendees` in a separate Text field if needed)
## Date
Use Date fields for any date value: an event date, a deadline, an anniversary, an effective-from date.
**Common Date use cases:**
* An `Event date` field on quotes for events
* A `Delivery date` requested by the customer
* A `Contract effective date` on a contract model
* A `Customer onboarding date`
**What Date accepts:**
* ISO 8601 format `YYYY-MM-DD` (recommended)
* Local format `DD/MM/YYYY` (displayed in the UI by locale)
**Display behavior:**
The format displayed in the UI follows the user's locale settings. The value stored internally is always a date — sort, filter, and date-arithmetic operations work consistently regardless of how it's shown.
Date fields don't currently store time — for an event with a specific hour like `16:00`, use a separate **Text** field labeled `Time` (this matches the pattern shown in many production setups).
## Choosing the right type
A few quick rules:
* If you'll **compute or aggregate** values (sum, average, sort numerically) → **Number**
* If you'll **filter by date range** or do date math (e.g., "quotes for events next month") → **Date**
* For **everything else** — labels, codes, descriptions, free-form data → **Text**
When in doubt, start with Text. You can always migrate to a more specific type later by exporting, deleting the field, recreating it with the new type, and re-importing the data with the right format.
## Related
Mandatory, Editable, Display — what these settings do.
Which objects accept custom fields.
Step-by-step example using Text, Number, and Date.
How types map to your CRM's field types.