Custom fields module — JetSetGo MCP reference

The customfields module is the definition catalogue for the extra questions operators attach to entities the platform already knows about: bookings, fare items (internally pat), resources, and service departures. It owns the question schema — input type, validation, display grouping, mandatory and manifest flags — across four data surfaces: the field definitions themselves, dropdown option sets, visual cluster headings, and a named regular-expression library. It deliberately collects no answers itself; consumer apps record answers against their own records.

What the operator uses it for

Extending data capture without code changes:

Adding a question at booking level (for example a damage-waiver acknowledgement) or per fare item.
Making a field mandatory, ordering it, and grouping related fields under a shared heading.
Defining the choices for dropdown and multi-select questions as batched option sets.
Building reusable regex validation patterns and attaching them to fields by reference.
Controlling whether a question appears on customer-facing manifests.

Where it sits

Definitions here are read at capture points — booking flows, fare-item-level entry forms, resource records, and service departures — while answers accumulate in a separate answer store owned by whichever consumer app asks the question. Because answers outlive their definitions, deletion is permanent but retirement keeps history interpretable. Validation patterns are referenced by id from fields; once attached, the pattern's details are copied onto the field server-side by a trigger.

Key concepts

Custom field — one extra question: internal name, human prompt (question_text), input type, attachment point, mandatory flag, manifest visibility.
Association type — which entity the question attaches to: booking, pat (fare item), resources, or service_departures.
Question type — general, limit, or track; classifies what the answer is used for.
Field type — fifteen input kinds: text, textarea, dropdown, multi-select, checkbox, radio, integer, decimal, date, time, datetime, yesno, email, phone, url.
Field option — one choice within a dropdown/multi-select question, carrying both a display label and an underlying value.
Display group — a heading that clusters related fields visually; identified by a short string key, not an integer.
Validation pattern — a named regular expression in a shared library with a configurable failure message.
Soft retirement — deactivating a field via active=0 so historical answers remain interpretable.

Tools

Tool	Class	Purpose
`customfields_list_fields`	Read	List field definitions, optionally filtered by association_type or active state, ordered by sort_key.
`customfields_get_field`	Read	Fetch one field definition by id.
`customfields_list_field_options`	Read	List the options belonging to a dropdown/multi-select field, with its parent field name.
`customfields_list_display_groups`	Read	List cluster headings ordered by sort_order.
`customfields_list_validation_patterns`	Read	List the named regex library.
`customfields_list_association_types`	Read	List which entity types can carry custom fields.
`customfields_save_field`	Guarded write	Create or update a field definition.
`customfields_delete_field`	Guarded write	Hard-delete a field definition.
`customfields_save_field_options`	Guarded write	Batch-upsert a field's options in one call (id present = update, omitted = create).
`customfields_delete_field_options`	Guarded write	Batch hard-delete specific options by id.
`customfields_save_display_group`	Guarded write	Create or update a cluster heading (string id).
`customfields_delete_display_group`	Guarded write	Hard-delete a cluster heading.
`customfields_save_validation_pattern`	Guarded write	Create or update a named regex pattern.
`customfields_delete_validation_pattern`	Guarded write	Hard-delete a validation pattern.

Rules worth knowing

Transport is mixed: fields, display groups, and patterns go through GraphQL CRUD; option sets use a REST batch upsert; hard deletes for fields, options, and groups run through a generic record-deletion endpoint, while patterns delete directly over GraphQL.
Never write the derived validation columns (validation_pattern, message, pattern field type) directly — they are populated server-side from validation_pattern_id. Setting the id is the only supported way to attach validation.
Display-group ids are short text keys (varchar(50)), not integers — every tool and read treats them as strings.
Flag conventions differ: active and mandatory are integer 0/1; manifest is boolean.
Creation minimums are enforced: a field needs name + field type + prompt + question type + association type; a display group needs name + icon + sort order; a pattern needs field type + pattern + description.
Prefer retiring a field (active=0) over deleting it — retirement preserves historical answers; deletion is irreversible.
Field reads are enriched with resolved display-group names via one follow-up lookup that degrades silently rather than failing the whole read.
All writes follow the guarded sequence — preview, explicit confirm with token, content-fingerprint drift check before execution — and require an explicitly stated tenant.

Bookings — booking-level custom questions are captured during booking creation and answered against booking records.
Resources — resources carry their own association type for compliance and specification questions.