Skip to main content
When you create a custom field in Settings › Data › Data Model, you define its name, API name, and data type. The field’s behavior (whether it’s required, who can edit it, who sees it) is configured separately, on each record. 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. For each field, you see:
  • A toggle to activate or deactivate the field on this record
  • The property checkboxes available for this object (see the table below)
  • The field’s input (text box, number, or date picker) for entering the value
On products, custom fields only have the toggle and the value (Attributes tab › Custom fields).
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 (for template fields, on each quote created from the template). 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: it’s typically filled 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

Display for customer

When enabled, the field appears on the buyer-facing quote (Dealroom and PDF). The customer sees the field’s label and value. 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:

How a field looks to each persona

  • The sales rep: sees every active field, and can edit those with Editable by sale ✓
  • The customer: sees only fields with Display for customer ✓
A custom field can carry information to the customer, or stay internal. The combination is yours to design.

Editing properties later

You can change the properties at any time on the record (customer, template, or contract model), then save it. Turning a field’s toggle off hides it from the record’s forms.

Field types

Text, Number, Date: the three data types available.

CRM mapping

Sync customer and quote custom fields with your CRM.

Create a Quote custom field

Practical example combining all three properties.

Manage roles

Who can edit the data model and Object fields.
Last modified on October 27, 2026