> ## Documentation Index > Fetch the complete documentation index at: https://bettertickets.gg/llms.txt > Use this file to discover all available pages before exploring further. # Settings > Every page in the /application edit menu explained in detail: General, Roles, Channels, and Questions, and what each individual field means. `/application edit category:` opens an interactive settings menu for one category. It has four pages, switched with a dropdown select menu at the bottom of the message - **General**, **Roles**, **Channels**, and **Questions**. This page goes through every field on every page, what it controls, and why you'd change it. ## General The panel's appearance, whether it's currently accepting applications, and how decisions get handled. * **Title / Description** - the heading and body text shown on the category's panel message. The default title includes your server's name automatically (`{{server.name}} Application`) - see [Variables](/docs/variables) if you want to customize this with dynamic text. * **Button label / Button style** - the text and color of the panel's Apply button. * **Status** - **Open** or **Closed**. Closing a category disables its Apply button and rebuilds the panel message to show it's closed, without deleting the category or its configuration - use this to temporarily pause applications (e.g. "recruitment is closed for now") without losing any settings. * **Associated ticket category** - links a ticket category to this application category, which adds an **Open Ticket** button to the submission message so staff can open a ticket with the applicant directly while reviewing (see [Overview](/docs/applications/overview#reviewing-from-the-submission-message)). Leave this on "None" if you don't want that shortcut. Categories linked to jail can't be selected here. * **Notify applicant on decision** - when enabled (the default), the applicant is DMed the result - accepted or denied - including the reason if staff gave one. Turn this off if you'd rather decisions stay silent and be communicated some other way. * **Reason required on accept** - whether staff must type a reason when clicking Accept or running `/accept`. Off by default, since acceptances often don't need justification. * **Reason required on deny** - the same, but for denials. **On by default** - the assumption is that a rejected applicant benefits from knowing why, and staff should have to articulate it. * **Submission message** Premium - the template used when posting a completed application to the submission channel. Supports [variables](/docs/variables), including `{{qa}}` to insert the formatted question/answer list - see the default template on the [Variables](/docs/variables#application-variables) page for a working example. * **Reapply cooldown** Premium - how long a denied applicant must wait before they're allowed to apply to this category again. Defaults to 3 days; write it as a duration like `3d`, `12h`, or `30m`. ## Roles Who can review applications, who gets notified, and what role changes happen at each stage. Every role list here is capped by your server's premium tier - see the [FAQ](/docs/faq) for the exact numbers. * **Staff roles** - members with any of these roles can review, accept, and deny submissions in this category (see [Staff roles vs. server permissions](/docs/tickets/overview#staff-roles-vs-server-permissions) - the same model tickets use applies here). Without this set, only server admins can act on submissions. * **Ping roles** - roles pinged in the submission channel the moment a new application comes in, so your reviewers know to check it without having to watch the channel manually. * **Assign on open** - roles given to the applicant the instant they confirm and start applying, before they've even answered a single question. Useful for tagging "applicant" status immediately, e.g. giving an "Applying" role that shows up in your member list. * **Assign on accept** - roles given when the application is accepted, e.g. the actual "Moderator" or "Staff" role this category is recruiting for. * **Remove on accept** - roles stripped when accepted, independent of whatever was given on open. Use this to clean up a temporary "Applying" role once someone's been accepted, without it lingering alongside their new role. * **Assign on denial** - roles given when the application is denied, e.g. a "Previously Denied" role you use for your own tracking. * **Blacklisted roles** - members with any of these roles can't apply at all, checked before anything else (see [Who can apply again, and when](/docs/applications/overview#who-can-apply-again-and-when)). ## Channels Where completed applications and activity logs go. Both are required for the category to be fully usable. * **Submission channel** - where completed applications are posted for staff to review, with Accept/Deny buttons attached. This is required - `/application send` refuses to post a panel until it's set, since there'd be nowhere for a completed application to go. * **Logging channel** - where open/submit/accept/deny events are logged as they happen, separate from the submission message itself. Use this for an audit trail of application activity without cluttering the submission channel with anything beyond the applications themselves. ## Questions The list of questions asked in DMs after a member confirms applying, one at a time - not a single modal, so it isn't limited to 5 questions the way [ticket questions](/docs/tickets/settings#questions) are. This is what turns an application category from a plain "click to apply" button into an actual form. Each question has: * **Label** - the question text shown to the applicant in their DMs. * **Description** - optional extra context shown under the label, for when the question itself needs more explanation. * **Input type** - either a text answer (with a character-length range you set, so it can act like a short answer or a full paragraph) or a select menu with options you define, for when you want a fixed set of choices instead of open text. * **Required** - whether the applicant must answer before continuing, or can skip it. Before submitting, the applicant sees a **review screen** listing every answer they've given, with a select menu to jump back and edit any specific one - so a typo in question 2 doesn't mean starting the whole application over. Once they confirm, that exact set of questions and answers is locked in for the submission, even if you change the category's questions afterward. How many questions you can add, and how many options a select-type question can have, both depend on your server's premium tier - see the [FAQ](/docs/faq). With zero questions configured, applying skips the DM conversation entirely and submits immediately on confirm - see [Overview](/docs/applications/overview#lifecycle).