> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Registration forms

> Build the questions attendees answer at checkout, attach a form to each ticket type, and read the answers on the attendee's page.

A registration form is the set of questions a person answers when they register — company, dietary needs, T-shirt size. You build forms once under **Registration form** in the event navigation, then attach one to each ticket type that should ask it. Name and email are always collected; they identify the registration and are not part of any form.

## Build and publish a form

<Steps>
  <Step title="Create a form">
    Click **Create form** and name it (e.g. "VIP questionnaire"). It starts as a draft.
  </Step>

  <Step title="Add questions">
    Use **Add item** to build the form. Question types include short answer, paragraph answer, single choice, multiple choice and dropdown, plus layout items — section titles, text paragraphs and media — that ask nothing.
  </Step>

  <Step title="Publish">
    A form has a **draft** half and a **published** half. You edit the draft; attendees only ever see the published version. Publishing snapshots your draft into what the public sees — until then, edits change nothing on the event page.
  </Step>

  <Step title="Attach it to a ticket type">
    Open a ticket type's page and pick the form in its **Registration form** section. That is where the binding lives — the forms page shows which types ask each form, but the choice is made from the ticket type's side.
  </Step>
</Steps>

## One form per ticket type

A ticket type carries **at most one form** — pick "None" and it asks only name and email. Several ticket types can share the same form, so a "General questionnaire" written once can be asked by every ticket. Need a variation? **Duplicate** an existing form and edit the copy.

## Reading the answers

* Each attendee's answers appear on their **attendee detail page**, under their registration.
* The form's **Responses** view lists everyone who answered, so you can read submissions form-by-form as well as person-by-person.

## Rules to know

* **Attendees only see the published version.** A draft edit — even to a form already in use — changes nothing until you publish again.
* **Forms never control access.** A form collects information; it cannot gate who may register, hide a ticket or hold a place. Use ticket type [visibility](/en/ticketing/ticket-types) and [redemption codes](/en/ticketing/offers) for access.
* **Name and email are built in.** They are always collected and cannot be removed; don't add them as questions.
* **An unpublished or archived form attached to a ticket type is flagged** on the ticket's page ("not published yet" / "archived") so you notice before attendees hit an empty form.
* **Forms archive rather than delete** — collected answers stay readable forever.

<Tip>
  Keep forms short. Every required question costs completions — ask at registration only what you need before the event, and collect the rest later.
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="Ticket types" icon="tickets" href="/en/ticketing/ticket-types">
    Where a form is attached — one per type.
  </Card>

  <Card title="Attendees" icon="users" href="/en/events/attendees">
    Where each person's answers are read.
  </Card>
</CardGroup>