Template fields

Fields are the custom pieces of information you capture beyond the built-in ones — a client's allergies, a marketing consent, a note on an appointment. They live in one place and are reused everywhere: your client list, the client record, your booking pages and the customer's self-service profile all draw on the same definitions.

Keep three choices apart. First you define a field once, on the Fields tab of the Templates page. Its settings then decide whether the customer site receives the field at all (Self managed) and whether the customer sees it in their own profile (Show in profile). Finally, on a booking template, a session resource or a product, you choose which fields that offer asks for at online-booking checkout. This page is the reference for all three; Configure checkout fields walks through them step by step and shows how to check the result as a customer.

The Fields registry

Open Templates > Fields. This is the master list of every field your organisation has defined. Pick the entity in the selector at the top — Client, Journal or Appointment — to see that entity's fields. A field belongs to exactly one entity:

• Client fields describe a person. They are the ones asked at checkout and in the customer profile, and shown in the client record and the client list.
• Appointment fields make up the form of a one-to-one appointment in the Scheduler.
• Journal fields belong to journal entries. No current dashboard or customer screen asks for them.

The list shows each field's identifier, not its heading, under Field, followed by the columns Required, Sensitive, Self managed, Show in profile, Searchable, Show in table, Scope (a pin for physical, a camera for video appointments) and Type. The search box (Find field) matches the identifier or the type.

Use the + button to add a field for the selected entity, drag a row by its handle to reorder it (order controls where the field appears in lists and forms, and the new order saves when you drop the row), and open a row — double-click it or use its eye icon — to edit it in full. The boxes in the list are live: ticking or clearing Required, Sensitive, Self managed, Show in profile, Searchable or Show in table saves at once and syncs. Changing fields needs Configuration & settings at Manage; with view access the list and the editor are read-only.

Defining a field

Opening a field opens the full editor.

• Entity — Client, Journal or Appointment.
• Type — the input control. The list shows the type names as go flow stores them, in every language: autocomplete, checkbox, consent, date, dropdown, mobile, number, process, radio, textarea and textbox. (You may also see existing tags fields, which display and filter normally but cannot be picked for a new field, and computed rows, which go flow owns — see Computed client-list columns.)
• Identifier — the field's internal name and the key the answer is stored under. It accepts letters only and at most 20 characters; anything else is stripped as you type. The hint below the box asks for at least ten letters; the editor itself marks identifiers shorter than five letters and saves any identifier that is not empty. Pick a clear, lasting name of five letters or more, such as allergies: clients never see it, but you do, because the field list and the checkout pickers show the identifier rather than the heading. Do not rename the identifier of a field that already holds answers (see Changing a field that is in use).
• Appointment types — whether the field applies to Physical appointments, Video appointments, or Both. The Video and Both options only appear when video appointments are available to your organisation (the Video module switched on with complete video credentials), or the field already has a video appointment type.

Headings, hints and translations

Every field needs a Heading for each of your organisation's languages (the boxes read Heading en, Heading de and so on, up to 50 characters) — this is the label the client actually sees, and the field will not save until every language has one. A per-language Hint is optional and appears as helper text beneath the input. The customer site shows each field in the customer's language; where that language has no text, it uses your organisation's default language.

Length

For textbox and textarea fields you can set a Max input length from 0 to 999. Choosing the type pre-fills a sensible default — 50 for a textbox, 500 for a textarea — which you can adjust. At 0 the booking site holds answers to the platform limit of 500 characters.

Options

Dropdown, autocomplete and radio fields (and legacy tags fields) carry a list of selectable Options. Add options with Add option, drag to reorder, and give each a Label per language. There must be at least one option, and every option needs a label in your default language before the field will save.

Each option keeps a stable internal identifier separate from its label, and that identifier — never the visible text — is what gets stored on the client record. So relabelling an option is always safe: renaming "Deutsch" to "German (Deutsch)", or fixing a typo, never rewrites or breaks answers clients already gave.

Column icon

For client and journal fields, Column icon shows an icon in the list header instead of the heading; the heading and hint become the column's tooltip. Pick a suggestion or type any Material Design icon name that starts with mdi-. Clear it to show the heading again.

Who sees a field: the settings

Each setting below is independent. The first four decide what the customer site does with a field; the others affect only the dashboard. The second column gives the label as the dashboard shows it in German.

Setting	German label	What it does
Use field	Feld verwenden	Ticked on the Fields tab of a booking template, session resource or product: that offer asks for the field at checkout, in the order you drag the rows. Only fields the customer site receives are asked (next row).
Self managed	Selbstverwaltet	The customer site receives the field: the customer can give it at checkout and, with Show in profile, keep it up to date in their profile. Off: the field never reaches the customer site — a ticked Use field is silently skipped and the field stays staff-only. process fields are the exception: the customer site always receives them. Off by default for a new field.
Show in profile	Im Profil anzeigen	Lists the field under Profile > Settings on the customer site, where the customer can change the answer and save. Works only for a field the customer site receives (Self managed, or a process field). A process field shows there as signed or not signed, read-only.
Required (in the editor: This is a required field)	Erforderlich (in the editor: Dies ist ein Pflichtfeld)	At checkout and group registration the customer cannot continue until the field is filled in; a required consent must be ticked and a required process field signed. The profile does not enforce it. In the dashboard an empty required field is marked in the client record, and every required client field is a fixed column of a session's participant list.
Show timestamp	Zeitstempel anzeigen	Consent and process fields: the customer's profile shows when the answer was last given ("Last updated:"). No effect on other types.
Show in table	In Tabelle anzeigen	Adds the field as a column of the dashboard client list, in the field order. Not available for a field that is logged now (see Privacy).
Searchable	Suchbar	The dashboard client search looks in this field. Not offered for consent and process fields, nor for a field that is logged now.
Sensitive	Sensibel	The answer is stored encrypted. Ticked and locked while the field's reads are logged (see Privacy). Not offered for consent and process fields.
Locked	Gesperrt	Consent and process fields only. The setting is saved with the field, but neither the dashboard nor the customer site acts on it at present.

None of these settings hides a field from staff: the client record in the dashboard shows every client field — or, when your organisation's Fields tab on the Organisation page holds a selection, every selected one.

Staff-only fields

A client field with Self managed off, and not of type process, is internal: the customer site never receives it, it is never asked at checkout or shown in the profile, and only staff see and edit it in the client record. Use such a field for information that belongs to your team — an instructor's assessment, an internal level, or a standing note about the client (a textarea suits notes). The answer is still personal data: it is part of the client's data subject export and follows the Privacy settings below.

Never switch Self managed on for the field your organisation uses as its Group membership field (on the Organisation page): customers could then choose their own group and unlock restricted sessions and member prices.

Privacy

Below the settings, the Privacy section says what kind of personal data the answer is and how closely it is protected. It appears for every field except consent and process fields.

• Data category — Identity, Contact, Booking, Financial, Health, Biometric, Special category or Other (the default). Health, Biometric and Special category are the protected categories.
• Read logging — Not logged, Logged when opened or Always logged: whether reading the answer is recorded. Logged when opened counts only while your organisation logs who reads client data; Always logged counts in every organisation. A protected category starts as Logged when opened.
• Retention (months) — from 0 to 120, counted from the day the client record is deleted: once the client has been deleted that long, the answer is cleared from the client, its bookings and its journal entries. 0 keeps the answer with the record.
• History — Every version, Latest value only or No history: how the record history shows the answer.
• Included in data portability export — puts the answer in the portability part of the data subject export. Until you set it, it follows Self managed.
• FHIR resource — shown only for the category Health: the health record type the answer becomes in a health care export.

A few rules apply:

• A field whose reads are logged is stored as Sensitive: the Sensitive box is ticked and cannot be cleared.
• While a field is logged now, its answer is loaded when a client is opened instead of arriving with the client list, so it cannot appear in lists or search. A field is logged now when it is set to Always logged, or to Logged when opened in an organisation that logs who reads client data (the health care profile always does). Show in table and Searchable are switched off and disabled for it in the editor, and the server refuses them. Where the organisation does not log reads, a field set to Logged when opened may still be a list column and searchable.
• A field in a protected category stays in one, and its read logging and retention can be raised but not lowered.

Audit settings and the health profile describes each setting and rule in full.

Consent and process fields

Consent and process fields capture agreements — a marketing opt-in, a liability waiver, a health declaration — rather than a plain value. They swap the Sensitive and Searchable options for Locked, have no Privacy section, and add Journal type, Interval and Linked documents. Only the client can give them (see Who can sign).

• A consent field is a checkbox, such as a marketing or newsletter permission. Choosing consent ticks Show in profile. The client's first answer is kept as their standing choice — leaving the box unticked at checkout counts as no — and checkout does not ask again once it is answered. The client can change it in their profile when the field is Self managed and Show in profile. Each change is recorded in the Journal.
• A process field is a declaration the client reads and signs. It takes a per-language Sub heading and a rich-text Content block (with bold, italic, underline, headings, lists and links). At checkout it appears as a card with its heading; opening the card shows the sub heading as the title and the content as the text, and the client must scroll to the end before Slide to accept works. A signature stays valid for the Interval; after that the client is asked again.

Choosing process pre-configures the field as required, locked, shown in profile, timestamped, not self managed and renewed every calendar year; choosing consent turns on Show in profile. Adjust these settings if needed.

Journal type

Journal type names the record each answer writes, and it is required: the editor will not save without one, and go flow refuses an active consent or process field that lacks it. It takes up to 60 characters. go flow does not check its format but matches it exactly, so use a short lowercase name with underscores — the hint suggests disclaimer, marketing_consent and newsletter_consent. It is the text the Journal shows for each answer.

• Give every consent or process field its own journal type. Two fields with the same journal type share one history: a signature on one counts for the other.
• Keep a journal type once answers exist. Earlier records stay under the old name, so after a change a process field asks every client to sign again, and the history of a consent starts afresh.

Interval

Interval decides when a process field must be signed again. It has no effect on consent fields: choosing consent clears it, and a consent stands until the client changes it.

Interval	German label	The client signs again
Once (one-time)	Einmalig	Never — one signature lasts.
Calendar year	Kalenderjahr	From 1 January of each year. The default for a new process field.
90 days, 180 days, 365 days	90 Tage, 180 Tage, 365 Tage	When the last signature is older than that.
(cleared)	(leer)	At every checkout.

The interval is checked whenever the client is next asked, so a change applies to existing signatures at once: shortening it asks earlier signers again.

Linked documents

Linked documents are named links to documents the client should review, each with a name and a URL, added with Add document. Note that these linked documents are stored on the field but are not currently shown to the client in the booking app, which displays only the inline rich-text content — so do not rely on an attached PDF being part of the customer-facing consent record.

Who can sign

Consent and process fields can only be given by the client, on the customer site: at checkout, when registering through a group link, or in their profile. Staff cannot tick or sign on a client's behalf, and the organiser of a group cannot sign for its members — each member signs their own when registering. In the dashboard the client record shows each consent and process field read-only: a green tick or a grey cross, the heading and the date of the last answer; click the row to see the IP address and the device it came from. A field the client has never answered reads "This field can only be set by the client".

A process signature cannot be withdrawn in the profile. When a session the client has booked lists a process field whose signature has lapsed, the profile shows "A signed liability disclaimer is required before your session." and lets the client sign there.

The standard field agreeToTerms works differently: when it is on an offer's checkout list, the customer accepts your terms with a checkbox at the foot of the checkout, on every checkout, and it never appears in the profile.

Check existing consent definitions before first checkout

Every active consent and process field needs a Journal type, including fields that are not on any checkout list. While one lacks it, every checkout and group registration of your organisation fails, and the customer sees only a general error such as "Failed to initiate payment" — even for a free booking. The editor and go flow refuse to save such a field today, but older definitions can still lack a journal type; check the standard agreeToTerms field in particular.

Open each existing Client field whose type is consent or process. If Journal type is empty, complete the definition with the agreed identifier for that purpose, then save and wait for dashboard sync. Preserve a populated identifier: it links the field to its existing history. Reload the booking page and complete one test booking. A saved field alone is not the success check; verify the confirmation and the active participant in the scheduler.

Computed client-list columns

Under Client, five rows of type computed are the client list's own columns, which go flow fills: by default Picture (an envelope for an invited client), Credit balance (only with the Wallets module), Voucher balance (only with the Vouchers module), Visits (in the last 12 months) and Last visit. They are fields so that you can show, hide and order them like any other column: tick or clear Show in table in the list, and drag the row. Their editor shows the note "go flow fills this column. You choose its heading, hint and icon, and whether the list shows it." and offers only the headings, hints, Column icon and Show in table. They cannot be deleted or created, and they are never asked at checkout, in the profile or in the client record. See Clients.

Changing a field that is in use

A field is shared: every booking template, session resource and product that ticks it, the client record and the profile all use the same definition. Answers are stored under the field's identifier, on the client and with each booking. What a change does:

Change	Effect on existing answers and offers
Heading, hint, option labels, order, Column icon	Safe. Answers stay; the customer site shows the new wording once the dashboard has synced and the page is reloaded.
Required, Self managed, Show in profile, Use field	Changes what is asked and shown from now on, for every offer using the field. Answers already given stay. With Self managed off the customer no longer sees or changes the field; staff still do.
Removing an option	Clients who chose it keep the stored choice, which no longer has a label: the dashboard shows an internal code instead.
Identifier	Existing answers stay under the old identifier, where no screen shows them, and checkout lists that name the old identifier stop asking for it. Create a new field instead.
Type	Existing answers may no longer fit the new control. Create a new field instead.
Journal type, Interval	See Journal type and Interval.
Deleting the field	The field leaves the forms, lists and checkout. Answers already stored are not erased.

Before relying on a shared change, check the offer you changed and one other offer that uses the field.

Saving and deleting

Click Save in the toolbar to apply your changes. It stays disabled until something has changed and the definition is complete: an identifier, a type, a heading in every language, a journal type for consent and process fields, and at least one labelled option for option fields. On an existing field, click the trash icon in the toolbar (tooltip Mark for deletion) to mark it for deletion; a warning banner appears and the rest of the form is locked. Click Save while marked for deletion to remove the field from the registry, or click the icon again to unmark it. Computed rows have no trash icon.

Choosing fields for checkout

Defining a field does not, on its own, ask anyone for it. A booking template, a session resource and a product each have their own Fields tab built from the same picker: tick Use field for each field that offer should collect, and drag to set the order. This produces the offer's checkout fields — the list asked for during online booking checkout. The picker lists client fields by identifier and shows the definition's Required and Self managed read-only. While the payments module is on, the three billing-address fields stay ticked and cannot be cleared (see Configure checkout fields).

Treatments and standard resources also show a Fields tab, but the customer checkout does not read it at present: an appointment with a treatment asks for the booking template's checkout fields. Aggregators have no Fields tab.

For the bigger picture of standing up a booking page, see Set up online booking.