Data model — CustomFieldDefinition
Defines the schema for custom fields that locations in a workspace can have. One definition per field type per workspace. Actual field values are stored on the Location model, not here.
Table: custom_field_definitions
| Column | Type | Nullable | Description |
|---|---|---|---|
| id | bigint | no | Primary key |
| workspace_id | bigint | no | Owning workspace |
| name | string | no | Internal key (slug-like, used to match location custom_fields) |
| label | string | no | Display label shown in the builder and widget |
| type | string | no | Field type enum (see below) |
| options | json | yes | Allowed values for constrained types (e.g. dropdown options) |
| required | boolean | no | Whether the field must be filled in before saving a location |
| sort_order | int | no | Display order (managed via reorder endpoint) |
| created_at | timestamp | — | — |
| updated_at | timestamp | — | — |
🔴 [NEEDS CLARIFICATION: Confirm the full type enum from the migration or model cast. Likely values: text, url, phone, email, hours, rating, image.]
Relations
belongsTo Workspace— workspace-scoped
Location values
Custom field values are stored in the Location.custom_fields JSON column as { field_name: value }. The name column on this model is the key used to match. If a definition is deleted, the orphaned values remain in location records.
Sort order
sort_order starts at 0 and is maintained by the POST /custom-field-definitions/reorder endpoint, which replaces all sort values atomically. Always include all definitions when calling reorder.
Related pages
- API — Custom Fields
- Data model: Location — where field values are stored
- Tags and custom fields