> For the complete documentation index, see [llms.txt](https://ticketking.xyz/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ticketking.xyz/docs/forms/questions-per-form.md). # How many questions a form can ask How long a form can be: 5 questions on the free plan, up to 100 on premium with multi-step forms. A Discord pop-up form holds at most **5 components**, and each question is one component. That is Discord's limit and it never changes. Premium lifts the cap on the form as a whole with **multi-step forms**. | Plan | Questions per option | | ------- | -------------------- | | Free | 5 | | Premium | Up to 100 | This applies the same way to ticket panels and application panels. ## Multi-step forms (premium) A premium option can go past 5 questions. Ticket King handles the rest: you add questions, the bot asks them all, and the member ends up in the same place with every answer in the ticket. There is nothing to configure — no "page" or "section" to lay out, no split to define. The member is guided through the whole form and their progress is kept as they go. ## What happens on the free plan A free server can still *save* more than 5 questions on an option — the dashboard just tells you the extra ones are inactive: > Free plan is limited to 5 questions — upgrade for up to 100 At ticket-open time, only the **first 5 active questions** are asked. The rest are kept, not deleted. That matters when premium lapses. Your longer form is not destroyed: it drops back to its first 5 questions, and if premium returns, the rest come back exactly as they were. You do not have to rebuild anything. If you want a different 5 while you are on the free plan, drag the questions you care about into the top 5 — order is what decides, not the Active toggle. ## What "1 component" means Every question is one component, whatever its type. Five text inputs is five components; four text inputs and a dropdown is also five. ## Just because you can ask 100, do not The cap is a ceiling, not a target. A good form is fast for the member. Five questions take about a minute; forty do not, and a member who feels interrogated writes worse answers or gives up before submitting. Some practical guidance: * **Support tickets: stay near 5.** The point of the form is to save one round of back-and-forth, not to replace the conversation. * **Applications: longer is reasonable.** Staff applications, whitelist applications, and partnership forms are where 15 to 30 questions genuinely earn their place, because the answers *are* the thing being reviewed. * **Put the questions you always need first.** On a free server only the first 5 are asked, and on any plan the first step is the one everybody completes. ## Asking fewer, broader questions Before adding a sixth question, check whether two of the first five can merge. **Four narrow questions:** 1. Operating system? 2. OS version? 3. App version? 4. Build number? **One Paragraph question instead:** 1. **Environment details.** Your OS, app version, and build number. The member writes everything in one paragraph. Staff still get all the information, faster. ## Using the opening embed instead Some "questions" are really instructions to the member, not information you need typed into a form. Move them out of the form and into the option's opening embed: > **Before staff can help with billing, please paste:** > > * Your order number > * The email on the account > * A screenshot of the error The member sees these once the ticket opens and provides them in their first message. ## Using Inactive questions Each question has an **Active / Inactive** toggle. Inactive questions stay saved but are never asked, and they do not count toward the steps a member walks through. Use it to test alternatives: draft 8 candidate questions, set 3 to Inactive, run the form with 5. After a week, look at what staff still have to ask in tickets, then swap the inactive questions in. ## What the cap does not mean * It does not limit what you can collect per ticket. Once the ticket is open, staff can ask anything in the channel. * It does not differ between tickets and applications. Both use the same form system and the same 5 / 100 split. ## Related {% content-ref url="/pages/7CkCeZCrgltqb0qqKg5z" %} [Question types](/docs/forms/question-types.md) {% endcontent-ref %} {% content-ref url="/pages/XQsrUSeSCzERWqbhESgi" %} [Applications overview](/docs/applications/overview.md) {% endcontent-ref %} {% content-ref url="/pages/exzL4IxFJ6d9jWNjp6BF" %} [The premium-only feature list](/docs/premium/feature-list.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ticketking.xyz/docs/forms/questions-per-form.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.