Forms
Registration questions, an exhibitor application, a support intake form, a task that needs a submission to close, a standalone client request — these read as unrelated features scattered across five sections of the product. They aren't. They're one form builder, attached to different places.
One builder, one field vocabulary
Every form in ema — regardless of where it's built from — is made of the same building blocks: short text, long text, email, phone, number, dropdown, radio, multi-select, checkbox, date, file upload, and section headings, laid out across one or more pages. Any field can carry conditional logic — shown or hidden based on a prior answer — so a form can branch without needing separate versions for separate audiences.
Build a form: fields, pages, conditional logic, and the public toggle.
A form has a type, and the type decides what it's attached to
When you create a form, you choose its type — Registration, Registration add-on, Talk, Exhibitor, Task, Vendor, Entitlement, Support, or General — and that choice decides which record the form's answers can write onto. A Talk-type form can map a question straight onto a talk's own fields or custom fields; a General-type form maps onto nothing and its answers live only as a raw submission.
This is a real attachment mechanism, not a hardcoded integration per module: adding a new place forms can attach to a record is a matter of adding a form type, not building a parallel form system for it.
One event uses the form builder four times: a Registration-type form collecting dietary requirements at checkout, a Talk-type form for the CFP asking for a session abstract, an Exhibitor-type form for booth compliance sign-off, and a General-type form for a sponsor enquiry with no target record at all. Same fields, same conditional logic, same editor — four different places the answers end up.
How a form field maps onto a real column or a custom field on the target record — and what "General" forms don't map onto anything.
Submissions live on the form — mostly
Every form keeps a Submissions table: every response, stored indefinitely, linked to the project. For a typed form, an answer does double duty — it sits in the submission record, and (where the form type supports it) it's written onto the target record's fields too, so a talk's abstract or an exhibitor's compliance answer shows up on the talk or exhibitor itself, not just in a list you'd otherwise have to cross-reference.
Support is the one type that diverges further. A support form's submission doesn't stay a submission — it becomes a ticket in a mailbox queue, with the form's answers mapped onto the ticket's own custom fields. If you're looking for a support form's responses, look in the support inbox, not on the form's Submissions tab.
How a support form's fields map onto ticket custom fields, and which mailbox it feeds.
Public forms are the same object, differently exposed
Every form has a shareable public URL — shown on the form's page in the admin as "Public Form URL" — that serves the identical form (same fields, same conditional logic) at an address that needs no sign-in. Nothing about the underlying object changes; only where it renders does.
Public support forms are a distinct path, not a public event form: they're served at their own URL or embeddable iframe, gated by anti-spam controls (a honeypot field and IP-based rate limits) because — unlike an event registration form — they're deliberately open to anyone who finds the link, including people who don't have an event to register for.
What a public-facing event form looks like to the person filling it in.
The separate, anti-spam-gated public path for support intake.
What isn't part of this system
A few features look like forms and use similar language but are separate, bespoke mechanisms — don't expect the form builder's field types, conditional logic, or Submissions table to apply to them:
- Polls and Q&A — its own builder with poll-specific types (multiple choice, rating, word cloud) and a Draft/Active/Paused/Closed lifecycle, not the form field vocabulary.
- Exhibitor content blocks (the "Why Visit" showcase) — a fixed set of content fields for booth marketing, not a form an attendee submits.
- CPD/CE self-attested claims — a reviewer queue built around uploaded evidence, not a form response.
If you're capturing structured answers that should attach to a real record (a registrant, a talk, an exhibitor, a ticket, a vendor), reach for the form builder before reinventing a bespoke field list — that's exactly what its typed attachment mechanism exists for.
A task's completion type can require a form submission before the task can close — the same shared form builder, attached to a Task-type form.
An approval-required registration type can attach a form so reviewers see supporting detail alongside the request.