Configure check-in fields
Check-in fields are the extra questions a participant answers on the check-in form before the check-in is recorded — a company name, a signature confirmation, anything you need captured alongside the check-in itself. This is a long one: it goes through both field types, how required fields are enforced, translations, ordering, and where the answers end up.
BEFORE YOU START
Attendance has to be enabled for the bundle before the Check-in Fields sub-tab does anything — see "Set up bundle locations" if you haven't turned it on yet.
What a check-in field is
A check-in field belongs to the bundle as a whole, not to one location — set it up once and it shows on the check-in form at every location in that bundle. Fields appear in the order you set them, each participant answers them once per check-in, and every answer is stored against that specific check-in record. From there, answers surface in three places: the location admin dashboard's per-row detail popup, the full CSV export, and the printable "currently checked in" sheet. Nothing about a field is bundle-wide scoring or pass/fail — it's purely information capture that rides alongside the check-in itself.
Add a field
From the Attendance tab, switch to the Check-in Fields sub-tab, next to Locations.
Choose Add Field.
Write a Label — the question or prompt text the participant sees, such as "Company name" or "I agree to the site safety rules".
Pick a Type: Text input or Checkbox.
Set Required if the participant must complete this field before the check-in is allowed to happen at all.
Choose Add Field to save it.
If the bundle offers more than one language, the same form grows an extra Label input per additional language, so the field can show a different label per locale. Leave a translation blank and that language falls back to the base Label instead of showing nothing.
Required vs optional, and how it's enforced
A required field is checked twice. The check-in form itself blocks the submit in the browser and shows an alert if a required field is missing, so most participants never even reach the server with an incomplete form. But the server checks again independently on every submission — looping through every configured field, confirming a required checkbox was actually set to Yes and a required text field isn't empty once trimmed. If either check fails, no attendance record is created at all: the participant is sent back to their dashboard with a banner reading "Please complete all required check-in fields." rather than a half-recorded check-in.
This matters because it means a required field is a real gate on the check-in itself, not just a nudge — nobody at that location gets recorded as checked in until every required field and, if the bundle has locations, the location dropdown too, is filled in.
A COMMON MISTAKE
Marking every field required can back up a queue at a busy check-in desk, since each one now blocks the whole check-in. Before switching a field to required, ask whether it truly needs to stop someone checking in, or whether it's fine as optional context you can review later in the export.
Reorder fields
Drag a field by its handle to move it up or down the list. Unlike page order in a course, this one saves itself the moment you drop it — there's no separate Save Order step to remember. The order shown here is exactly the order participants answer the questions in on the check-in form, so it's worth a moment's thought.
GOOD TO KNOW
Put a required field near the top of the list rather than after two or three optional ones. A participant who hits a blocking required field late in a long form is more likely to give up than one who sees it first.
Edit or remove a field
Editing lets you change the label (and its per-language translations), the type, and the required flag at any time — existing answers already recorded aren't rewritten to match a later edit. Deleting asks for confirmation and removes the field from the form immediately, but it doesn't retroactively touch answers already given under the old field: those responses stay in the database, just with no field left to name them.
That last part has a practical consequence worth knowing before you delete anything: since exports build their columns from the field's label, and a deleted field has no label left to look up, historical answers recorded against it simply stop appearing in new exports. The data isn't destroyed, but it becomes invisible from that point on — editing a field's label is almost always the better choice if you just want to correct wording.
Where responses end up
Every answer is saved the moment a check-in succeeds, and shows up in three places without any extra setup:
"Export the attendance log" covers both downloads in detail, including exactly how the CSV's columns are built.
If something isn't working
What next
With locations and fields both set up, the check-in form is complete from the admin side. Next, see it from where it actually matters — the participant's own dashboard.