Skip to main content
An application category is a self-contained form: members apply from a panel message, answer a set of questions in their DMs, and staff review the completed submission and accept or deny it. It’s commonly used for staff recruitment (“Apply to be a moderator”), but works for any structured form you’d otherwise build with a Google Form and manual copy-pasting into Discord. This page walks through creating and editing a category, then explains the full lifecycle from someone clicking apply to a decision being made.

​
Creating and editing a category

Like ticket categories, an application category always needs two steps: create it, then configure it.
1

Create the category

Run /application create id:<name>, for example /application create id:mod-team. This registers a new, empty category. id becomes the category value used everywhere else, including /application edit - you can’t rename it later, only delete and recreate it.
2

Edit the category

Run /application edit category:mod-team. This opens an interactive settings menu with four pages (General, Roles, Channels, Questions), switched with a dropdown at the bottom of the message. Full field-by-field details are in Application settings.At minimum, set a submission channel (Channels page) - the panel can’t be sent without one - and add at least one staff role (Roles page) so someone can review submissions.
3

Add questions (optional)

Still on the Questions page, add whatever you want to ask applicants - a label, an input type (free text or a select menu with your own choices), and whether it’s required. If you skip this entirely, applying submits immediately when a member confirms, with no DM conversation at all.
4

Send the panel

Run /application send category:mod-team channel:#applications. This posts the message members click to apply. Like tickets, you can send the same category’s panel to more than one channel.

​
Lifecycle

Once a category is configured and its panel is sent, here’s what happens from a member clicking apply to a decision being made:
  1. Apply. A member clicks Apply on the panel, or runs /apply category:<name>, and confirms. The bot checks their eligibility first (see below) - if they’re not eligible, they’re told why and nothing else happens.
  2. Questions, or immediate submission. If the category has questions configured, the bot DMs them one at a time, waiting for an answer to each before sending the next. Once every question’s answered, a review screen shows every answer with a select menu to jump back and fix any of them before submitting. If the category has zero questions, there’s nothing to ask - the application submits the moment they confirm, with no DM conversation.
  3. Submission. Once every question is answered (or immediately, if there were none), the completed application posts to the category’s submission channel as a formatted message with the applicant’s answers, plus Accept and Deny buttons and, if configured, an Open Ticket button.
  4. Review. A staff member with this category’s staff roles clicks Accept or Deny (or runs /accept//deny), optionally providing a reason. The submission message updates in place immediately - the buttons are removed, the accent color changes to green (accepted) or red (denied), and a footer is added showing who decided and when.
  5. Notification. If Notify applicant on decision is enabled (it is by default), the applicant is DMed the result, including the reason if one was given.
See Commands for the exact options every command in this list takes.

​
Who can apply again, and when

Before letting someone start an application, the bot checks four things in order - the first one that applies wins:
  1. Blacklisted role. If the applicant has a role on the category’s blacklist, they’re blocked outright, regardless of any application history. This check always runs first.
  2. An application already in progress. If they’re mid-way through answering DM questions for any category on any server (not just this one), they’re blocked from starting another. This exists because there’s only one DM conversation to answer questions in - starting a second would collide with the first.
  3. A submitted application awaiting review. If they already have a completed, not-yet-decided application in this server, they’re blocked from applying again until it’s decided.
  4. A recent denial. If their most recent decision for this category was a denial, they’re blocked until the category’s reapply cooldown passes (default 3 days, editable on premium tiers - see Application settings). They’re told exactly when they’ll be able to reapply.
An accepted application never blocks reapplying - there’s no cooldown after an accept.

​
Roles

Configured on the category’s Roles page (full details in Application settings):
  • Staff roles - who can review, accept, and deny.
  • Ping roles - pinged on the submission message.
  • Assign on open - given the moment the applicant confirms and starts.
  • Assign on accept / Remove on accept - role changes applied when accepted.
  • Assign on denial - role given when denied.
  • Blacklisted roles - can’t apply at all.
Role list lengths and question counts scale with the server’s premium tier. See the FAQ for the exact limits.

​
Reviewing from the submission message

If a ticket category is linked in Associated ticket category (General settings), the submission message gets an Open Ticket button alongside Accept/Deny. Clicking it opens a normal ticket with the applicant directly from the review message - useful for asking a follow-up question before deciding, without needing the applicant to separately find and use a ticket panel. It won’t open a ticket in a category linked to jail, since jail categories can’t be opened through the regular ticket flow at all.