> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alforse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom fields

> Company-defined extra fields that attach to core records like customers, parts, and orders.

Custom fields add company-specific data to supported records without database schema changes. Define a field under **Settings → Custom Fields**. Alforse adds it to the entity's form, stores it with built-in fields, and exposes it through the API.

## Defining a field

Alforse screenshot**Settings → Custom Fields: the entity catalog with Table, Module, and Fields columns, and the field form with name, data type, and tags**

One row per eligible entity; the field form locks its data type after creation.

FieldType

<details>
  <summary>**Name**required`text`</summary>

  The label shown on the record's form. Unique per table, per company.
</details>

<details>
  <summary>**Data Type**required`enum`</summary>

  One of nine types (below). **Once saved, the type can't be changed**; delete and re-create to switch.
</details>

<details>
  <summary>**List Options**`text[]`</summary>

  Required only for the **List** type: the dropdown's choices.
</details>

<details>
  <summary>**Required**`boolean`</summary>

  The field must be filled before the form saves. Boolean fields are never treated as required.
</details>

<details>
  <summary>**Tags**`text[]`</summary>

  Scopes the field to records carrying a matching tag; leave empty to show it on every record of the table.
</details>

The nine data types are **Yes/No** (boolean), **Date**, **List**, **Numeric**, **Text**, **User**, **Customer**, **Supplier**, and **File**. The three reference types store a reference to an existing Alforse record rather than free text. Forms render inputs for the first eight; **File** is defined but has no input on the entity form yet.

NOTE

**The data type is permanent**

Alforse locks the data type after creation. To change it, create a replacement field and migrate existing values.

## Which entities support custom fields

The catalog is curated, not universal — the settings page lists one row per eligible entity with its module and field count. Coverage spans most modules: **Sales** (customer, quote, sales order, sales invoice, RFQ, their contacts, locations and lines), **Purchasing** (supplier, purchase order, supplier quote, purchasing RFQ, their lines and contacts), **Invoicing** (purchase invoice, payment, memo), **Items** (part, tool, material, consumable, fixture, service, costing/planning records; see [items](/docs/reference/items.md)), **Resources** (employee job, work center, department, location, process, shift), **Inventory** (receipt, shipment, warehouse transfer, picking list, shelf), **Production** (job), **Quality** (gauge, issue) and **Accounting** (account, payment term, journal). An entity not listed on the settings page isn't supported yet.

## How values save, and where they reach

Custom inputs appear below built-in fields and save to the entity's `customFields` JSON column. The API exposes this column for reads and filters. Its keys are field IDs, not display names, so use the settings catalog to resolve definitions.

HEADS UP

**CSV import and export skip custom fields**

The CSV flows map built-in fields only; neither import nor the table download touches the `customFields` column. Populate custom fields on the form or through the API; see [import and export](/docs/reference/import-export.md) for what CSV does cover.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.