> ## 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 properties
> Mandatory, Editable by sale, and Display for customer — control where custom field values flow.
When you create a custom field in **Settings → Data → Data model**, you define its name, API name, and data type. But the field's **behavior** on each object — whether it's required, who can edit it, who sees it — is configured separately, on the object itself.
This page explains the three properties Qwoty offers and how to combine them for the most common patterns.
## The Custom Fields section on each object
Once a custom field exists in the Data model, it appears in the **Custom Fields** section of every record of the matching object (or the relevant Template, for Quote). For each field, you see:
* A **toggle** to activate or deactivate the field on this object
* Three checkboxes: **Mandatory**, **Editable by sale**, **Display for customer**
* The field's input area (text box, number, or date picker) for entering the value
If a custom field doesn't appear on the object after creation, check that its toggle is **on** in the Custom Fields section. Disabling the toggle hides the field from forms while keeping its definition intact.
## The three properties
### Mandatory
When enabled, the field **must be filled** before saving the record (or, for Template-driven fields, before the quote can be submitted).
**Use Mandatory when:**
* Missing the value would block downstream processes (for example, a `Delivery date` required by your warehouse)
* Compliance or contract generation depends on it (a `Jurisdiction` field for legal templates)
* Your reporting needs the field populated to produce useful KPIs
**Don't use Mandatory when:**
* The field only applies to some records (a `Hectares` field that's relevant for agricultural customers but not retail customers)
* The value is filled in later in the deal cycle (a `Signed date` you can only fill at signature)
### Editable by sale
When enabled, sales reps can modify the field's value. When disabled, the field is **read-only** for sales reps — typically populated by an admin, an integration, or an import.
**Use "Editable by sale" when:**
* Sales reps own the value (an `Event date` they collect from the customer)
* The field is part of the sales-rep workflow
**Disable "Editable by sale" when:**
* The value comes from your CRM and shouldn't be overwritten by mistake
* Only admins should set the value (a `Discount tier` linked to negotiated commercial terms)
* The value is calculated by an integration
"Editable by sale" controls the **sales rep** experience. Admins can always edit custom fields regardless of this setting.
### Display for customer
When enabled, the field appears on the buyer-facing quote and Dealroom. The customer sees the field's label and value alongside the line items, dates, and totals.
**Use "Display for customer" when:**
* The buyer needs the value to make a decision (an `Event date` so they can confirm scheduling)
* The value is part of the commercial terms (`Headcount`, `Delivery window`)
* The information is meant to be transparent
**Don't use "Display for customer" when:**
* The field is internal metadata (an `Account manager code`, `Sales region`)
* It's used only for reporting or accounting (a `Ledger code`)
* Sharing the value would expose internal pricing logic
## Common patterns
These combinations cover most setups:
| Pattern | Mandatory | Editable by sale | Display for customer | Example |
| ---------------------------- | --------- | ---------------- | -------------------- | ---------------------------------------------- |
| **Customer-facing required** | ✓ | ✓ | ✓ | Event date on a quote |
| **Customer-facing optional** | — | ✓ | ✓ | Special instructions |
| **Internal sales note** | — | ✓ | — | Sales rep's deal context |
| **Admin-controlled visible** | — | — | ✓ | Negotiated discount tier shown to the customer |
| **Admin-only metadata** | — | — | — | Account manager code, ledger account |
| **CRM-synced read-only** | depends | — | depends | Customer industry pulled from HubSpot |
## How a field looks to each persona
The three properties shape what each persona sees:
* **The admin** — sees and edits every custom field, regardless of properties
* **The sales rep** — sees every active field; can edit only those with **Editable by sale** ✓
* **The customer** — sees only fields with **Display for customer** ✓ on the published Dealroom
A custom field can carry information that flows through all three personas, or stay internal. The combination is yours to design.
## Display badge on the customer view
When a field is set to **Display for customer**, it shows up on the Dealroom with a violet **Display** badge (visible in admin preview mode). This badge confirms that the field will be visible to the buyer when the quote is published.
The Display badge only appears in the admin preview to remind your team which fields are exposed. The customer doesn't see the badge — they see the field's label and value styled like the rest of the quote.
## Editing properties later
You can change any of the three properties at any time. Changes take effect for **new** records and the **published** state of existing records:
* Toggling **Mandatory** on doesn't retroactively block existing records — only saves and submits going forward
* Toggling **Display for customer** on republishes the field to existing Dealrooms the next time the quote is updated
* Toggling **Editable by sale** off immediately makes the field read-only for sales reps
Disabling the field's toggle entirely (in the Custom Fields section) hides the field from all forms but **preserves stored values**. Re-enabling restores the field with the values intact.
## Related
Text, Number, Date — the three data types available.
Configure sync direction and CRM field for each custom field.
Practical example combining all three properties.
Who can edit the data model and Object fields.