Custom Field Data Types

Types for custom fields — tenant-defined metadata on governance entities.

Enumerations

Both SDKs export these as named types, so you get autocomplete when creating or updating a definition. Responses carry them as plain strings, so a value added to the platform later widens a response rather than breaking a read.

Type	Values
CustomFieldType	string, number, datetime, user
CustomFieldElementType	input, checkbox, select, datepicker

CustomFieldDefinition

What a custom field is. Defined once per tenant and applied to entities.

Field	Type	Description
id	string	Unique identifier for the custom field.
name	string	Display name.
type	string	Value type: string, number, datetime, or user.
element_type	string	Input control: input, checkbox, select, or datepicker.
options	string[]	Permitted values, for select fields. Empty when unrestricted.
multiple	boolean	Whether the field accepts more than one value.
metadata	object	Additional configuration, such as min and max for a number.
entity_type_ids	string[]	Entity types this definition applies to. An empty list means it applies to all of them.

CustomFieldCreate

The request payload for defining a new custom field.

Field	Type	Description
name	string	Required. Display name.
type	CustomFieldType | null	string, number, datetime, or user. Defaults to string.
element_type	CustomFieldElementType | null	input, checkbox, select, or datepicker. Defaults to input.
options	string[] | null	Permitted values, for select fields.
multiple	boolean | null	Whether the field accepts more than one value.
metadata	object | null	Additional configuration, such as min and max.
entity_type_ids	string[] | null	Entity types the field applies to. Omit it, or pass an empty list, for every entity type.

CustomFieldUpdate

The request payload for changing a definition. Every field is optional; only the attributes supplied are changed. Fields are as CustomFieldCreate, except that name is optional and entity_type_ids is add-only — entity types can be added to a definition but not removed from it.

CustomFieldValue

One entity's value for a definition.

Field	Type	Description
custom_field_id	string	The custom field this value belongs to.
name	string | null	Display name of the custom field.
value	string | number | boolean | string[] | null	The current value. null when unset.
entity_id	string | null	The entity holding this value.
definition	CustomFieldDefinition | null	The definition this value belongs to.

CustomFieldValueUpdate

The request payload for setting a value.

Field	Type	Description
custom_field_id	string | null	Set one field, by ID.
name	string | null	Set one field, by name.
values	object | null	Set several fields at once — a map of field name to value.
value	string | number | boolean | string[] | null	The value, when setting one field. A list for multi-value fields; null clears it. Not used with values.

Exactly one of custom_field_id, name or values is required; anything else is a 422.

The response is always a list, whether you set one field or several.

With values, every name is resolved against the entity's definitions before any write happens, so an unknown or ambiguous name fails the request with nothing applied. Once writing starts the fields go one at a time, so a failure there — a value outside a field's options, say — leaves the earlier fields written.

How values are typed

A value's shape on read follows the definition, not what you sent:

Definition	You send	You read back
type: string, multiple: false	"Finance"	"Finance"
type: string, multiple: true	["Finance", "Legal"]	["Finance", "Legal"]
type: number	2.3 or "2.3"	2.3
type: datetime	an ISO 8601 string	the same string
type: user, multiple: false	a user ID	the user ID
type: user, multiple: true	a list of user IDs	the list
any, no value set	—	null

Values are stored as text and coerced on read, so a number field returns a number rather than a string. Sending a value that does not match the definition — a non-numeric string for a number field, or a value outside options for a select — is rejected with a 422.

Field names are not unique

The only uniqueness constraint on a custom field name is a legacy one that is being retired, so a definition applying to every entity type and one targeted at a specific type can share a name. When you address a field by name, it is resolved against the definitions that apply to that one entity, and an ambiguous name is rejected rather than silently resolved to one candidate. The error lists the candidate IDs so you can pass custom_field_id instead.