Custom Fields

Custom fields let teams add structured data to supported entities without opening a database change for each variation.

What custom fields include

Each field definition includes:

• entity type and field key
• field label and field type
• required flag and display order
• default behavior
• validation rules
• UI settings (for example placeholder, hidden, read-only, options)

Supported field types

Current field types are:

• string
• number
• boolean
• date
• json
• array
• computed
• select

How change control works

Custom field definitions follow approval workflow before they become active. A definition can be created and edited, then submitted and approved under maker-checker controls.

This prevents unreviewed field changes from appearing in live operations.

Runtime behavior on forms and details

When a supported entity is opened in create, edit, or detail view, the runtime layer loads active definitions for that tenant and entity type.

At runtime, the platform applies:

• type normalization
• defaults
• computed values
• validation
• hidden/read-only behavior from UI config

The backend remains the source of truth for final validation.

Defaults and computed fields

Default strategies include:

• static
• rule-based
• computed

Filtering and search

List endpoints support custom field filtering using field__operator syntax.

Examples:

tax_id__contains=ABC
priority__gte=5
effective_date__between=2026-01-01,2026-12-31
is_blacklisted__isnull=true

Supported operators include:

• equals (eq)
• not equal (ne)
• greater than (gt)
• greater than or equal (gte)
• less than (lt)
• less than or equal (lte)
• in list (in)
• not in list (nin)
• contains (contains)
• contains (case-insensitive) (icontains)
• starts with (startswith)
• ends with (endswith)
• is null (isnull)
• between (between)

Availability across the product

Custom fields are enabled per entity. Not every entity has runtime custom fields by default.