Pre-Meeting Forms
Collect the info you need before the slot is confirmed — text fields, dropdowns, checkboxes, and file uploads.
Pre-Meeting Forms
A pre-meeting form is a set of fields the attendee must fill out before the booking goes through. Use it to qualify leads, collect intake info, or require uploads (e.g. a brief, a portfolio, or a signed NDA) ahead of the call.
The form is per-link, so a sales rep's discovery-call link can ask different questions than a recruiter's interview link.
Screenshot needed — public booking page showing the pre-meeting form between the slot picker and the confirm button
Enabling the form
In /settings/booking-links/<id>:
- Toggle Pre-meeting form to On.
- Add fields. Each field has:
| Property | Value |
|---|---|
| Label | What the attendee sees (e.g. "What's your team size?") |
| Type | One of: text, textarea, select, checkbox, file |
| Required | If yes, the attendee can't submit until they fill it in |
| Options | For select only — list of choices |
| Accept | For file only — MIME types (e.g. image/*,application/pdf) |
Up to 20 fields per link. There's no required-field minimum — leave the form empty if you only want it for the public-page header.
Field types
Text
A single-line input. Max 5000 chars (server-enforced). Best for short answers like company name, role, or website.
Textarea
A multi-line input. Same 5000-char limit. Best for "tell me what you'd like to talk about" or freeform context.
Select
A dropdown of pre-defined choices. The attendee must pick one of the listed options — they can't type a custom answer. Useful for budget brackets, team-size buckets, or routing categories.
Checkbox
A single boolean. If marked required, the attendee must check it to proceed (e.g. accepting terms). If optional, they can submit either way.
File
An upload widget. Files are stored in Workestra's secure storage and referenced from the booking record. The attendee gets a link in their confirmation email; the host can download from the booking detail.
Files are validated server-side against the configured accept types and a size limit. The booking itself is rejected if validation fails — the attendee sees an error before the slot is confirmed.
What happens to the responses
Form responses are stored on the scheduling_calendar_events row as JSON. They appear:
- In the host's confirmation email — inline, as a labeled list
- On the calendar event detail panel — once the AI panel ships in Phase 3 (see the completion roadmap)
- In the auto-created CRM deal's notes — if the link has
auto-create dealon - Via the public API — once
/api/v1/bookingsships in Phase 2
Validation
The server validates every field at booking time:
- Required fields — must be present and non-empty
- Select fields — must match one of the listed options (string match)
- Checkbox fields — must be a boolean; if required, must be
true - Text/textarea — must be a string ≤ 5000 chars
- File fields — must reference a valid uploaded
storage_path
If validation fails, the attendee sees the first error inline and the booking is not created — the slot stays available.
When not to use it
- As a lead-qualification gate. If your goal is "only qualified leads get a meeting," you'll get more value out of an outbound qualification form (e.g. a Workestra Form, when that ships) that lives on a landing page — not on the booking page itself, where the attendee has already made a commitment.
- For long surveys. The form sits between the slot picker and the confirmation. More than ~6 fields and you'll see drop-off. Keep it short; ask the rest in the meeting.
- For NDAs. A checkbox is not legally enforceable as a signature. Use a real e-signature flow (planned: Contracts module) for anything that needs to hold up.
Read next
- Booking Links — the per-link settings the form lives under
- Calendar Dashboard — review form responses for past meetings