Configure checkout fields

Every online booking ends the same way: your client fills in a short form before they pay. You decide what that form asks — and, as a separate choice, what the client can later review and change in their own profile. It is a two-step idea — first you define a field once for your whole organisation, then you select that field on each offer so it gets asked at checkout. This guide walks through the whole pipeline, from creating a field to seeing it at checkout and in the customer profile, with a worked example you can follow step by step.

Before you start

• Configuration & settings at Manage, to edit fields and booking templates.
• A booking template that is online, and its link — see Set up online booking.
• An email address you can read, for a test client. Create the test client first under Clients with +, so that it appears in your client list.

Define your fields on the Templates page

Open Templates > Fields. This is your organisation's master list of custom fields — the place they are created, listed, and reordered. Pick Client in the entity selector (checkout fields are always client fields), then click + to add one. Each field opens in the field editor, covered in detail in Template fields.

Worked example — a "Marketing email consent" field. Use an optional consent field for marketing emails, with wording approved for your business. Keep this separate from operational reminders and required booking declarations.

1. Set Type to consent and Entity to Client.
2. Give it an Identifier of marketingConsent (letters only, five or more is best).
3. Fill in the Heading for each of your languages — this is the wording the client actually reads, e.g. "I agree to receive marketing emails."
4. Enter a Journal type such as marketing_consent — consent and process fields require this. Leave Interval empty: a consent stands until the client changes it; only process fields are renewed.
5. Tick Self managed. Without it the customer site never receives the field, and checkout skips it without warning. Keep Show in profile, which choosing consent ticks for you, so the client can change their mind later in their profile.
6. Leave This is a required field off so declining marketing does not prevent a booking, and leave Show in table off so it does not clutter your client list.

Save, and it joins your master list. In the dashboard the field always appears read-only — only the client can answer it, on the customer site.

A second field — "Allergies". Add another: Type textbox, Identifier allergies, a heading of "Any allergies we should know about?", tick Self managed, and leave it optional. Tick Show in profile as well if clients should keep it up to date themselves. A textbox defaults to a 50-character limit, which you can raise on the same screen. Allergies are health information: under Privacy, set Data category to Health (see Template fields). Save it too.

Select those fields at checkout

Defining a field does not, by itself, ask anyone anything. You now choose it on each offer. Open the booking template you set up in Set up online booking and go to its Fields tab (session resources and products have the same tab).

You will see your client fields listed by identifier under Field, with a Use field checkbox on each row, plus columns showing Required, Self managed, Scope, and Type. Tick Use field for marketingConsent and allergies, then drag the rows to set the order the client sees them. Save the template.

The Required and Self managed columns here describe the shared field definition; they are not per-template switches. To change them, return to Templates > Fields and edit the definition. That change affects every offer using the field. Check both the new offer and another affected offer before publishing a shared change. A ticked field whose Self managed box is empty is not asked (unless it is a process field): fix the definition, not the list.

Treatments and standard resources also have a Fields tab, but the customer checkout does not read it at present. For appointments with a treatment, select the fields on the booking template.

Before the first test checkout, also check existing consent definitions. Do not assume pre-existing fields are complete merely because you did not create them.

Checkout fields and profile fields are separate choices

The checkout form and the customer's profile are filled from different settings. Ticking Use field on an offer does not put the field in the profile, and Show in profile does not put it on the checkout form. Mix them up and checkout asks for everything while the customer's profile stays almost empty.

Self managed	Show in profile	Use field on the offer	At checkout	In Profile > Settings
On	On	Ticked	Asked	Shown; the customer can change it
On	Off	Ticked	Asked	Not shown
On	On	Not ticked	Not asked	Shown; the customer can fill it in
Off	Either	Either	Not asked	Not shown — a staff-only field

A process field is the exception to the first column: the customer site always receives it, so Use field alone puts it on checkout, and Show in profile shows its signed status, read-only, in the profile.

For each field decide: should the customer give it when booking (tick Use field on the offers that need it), keep it up to date themselves (Self managed and Show in profile), or never see it (Self managed off)? Required applies at checkout and group registration only; in the profile the customer can save with a required field empty. Template fields explains every setting.

What the customer is actually asked

Here is the part worth understanding. At Online booking checkout, the form is not taken from a single list. The customer is asked for the merged, de-duplicated set of fields from every item in their cart — each session's own fields, each product's fields, and finally the booking template's list, combined in that order with duplicates removed. An appointment with a treatment adds no list of its own.

So if a client books a yoga class (whose session resource asks for Allergies and Marketing email consent) and adds a gift voucher product (which asks for a Recipient name), the single checkout form they see contains all three fields once each, followed by the fields of the booking template's list — even though you configured them on unrelated screens. Ask only for what you genuinely need on each item; the cart does the assembling for you.

Some selected fields do not appear as inputs:

• a field whose definition is not Self managed (process fields excepted) — the customer site never receives it;
• a consent the client has already answered, yes or no;
• a process field whose signature is still valid for its interval — it shows as signed;
• the email address, once the client is signed in;
• agreeToTerms, which becomes the terms checkbox at the foot of the checkout.

Group members who did not buy. Someone who registers through a group booking's link or QR code is asked the session's own fields and the booking template's list — no product fields, and no billing address, because they pay nothing. Their answers are stored on their own client record and with their place in the session, and they sign their own consent and process fields. See Session participants.

The billing address, when you take payment

Three client fields carry the billing address: Street and number (identifier addressLineOne), Postal code (postalCode) and City (city). Country is not required. While your payments module is on:

• go flow adds them. Each time the organisation is saved with payments on, go flow creates any of the three fields your organisation lacks (with Self managed and Show in profile on) and adds them to every booking template's checkout list. A field created this way has no heading yet: open it in Templates > Fields and give it a Heading in every language, otherwise the customer sees the identifier.
• They cannot be unticked. On the Fields tab of a booking template, session resource or product they are ticked with a greyed Use field box; its tooltip reads "Required for paid checkout while the payments module is on". Reorder them freely. A list saved without them gets them back the next time you open and save it.
• They become required when there is something to pay. When the cart still has an amount to pay after wallet credit and vouchers, checkout makes the three required, whatever their own Required setting. A free booking, or one fully covered by credit or a voucher, does not insist on them. A card payment without them is refused, and the customer sees "Please provide your full billing address (street, postal code, city, country)".

If you switch payments off, the fields stay defined and selected — nothing is removed — they simply stop being required at checkout, and you can untick them. Switch payments back on and they are locked and required again.

That is the one place the two-step idea does not apply, and deliberately so: leaving them out is not a choice, it is a checkout that cannot complete.

Check the result as a customer

Do this after you set up fields and after any change to a shared field.

1. In Templates > Fields, choose Client and check the Self managed and Show in profile columns for every field the customer should keep up to date. Wait until the dashboard has synced.
2. Open the booking page link in a private browser window and book as the test client — a free session or appointment if you have one. Check that the form asks for the fields you selected, in your order.
3. Open Profile, sign in with the test email address and the one-time code sent to it, and open the Settings tab.
4. Check that every field you expect is listed. Change a harmless value — the test client's city, for example — and click the save button (the tick at the bottom right). "Changes saved" appears.
5. Reload the page and open Profile > Settings again. The new value must still be there.
6. In the dashboard, open the test client under Clients: after the next sync the record shows the new value.
7. Change the value back, and cancel the test booking.

The result to expect: checkout asks for what each offer selects, the profile lists what is self managed and shown in the profile, and a saved change survives a reload and reaches the client record.

When something is missing:

• A field is not on the checkout form: tick Use field on the booking template, or on the session resource or product in the cart, and make sure the definition is Self managed (process fields excepted). A consent the test client answered before is not asked again — test with a new email address.
• A field is not in Profile > Settings: the definition needs Self managed and Show in profile (a process field only Show in profile). agreeToTerms never appears there.
• A change does not show on the customer site: wait for the dashboard to finish syncing, then reload the booking page; a page left open keeps the old settings.
• The customer sees an identifier instead of a label: add the missing Heading for that language.
• "Failed to save changes" in the profile: nothing was saved. Try again; if it repeats, note the field and the time and contact go flow support.
• Checkout fails with a general error: check existing consent definitions.

That is the whole pipeline — define once on the Fields tab, decide what the customer site receives and shows in the profile, select per offer, and let checkout merge the result into the exact form your client fills in.