DOCUMENTATION

Application management

Submitt applications are Discord-native. Members click Apply and complete on-screen modal pages inside Discord instead of being pushed into a DM conversation or external form. Owners build the form and review workflow from the website dashboard.

Create an application form

Open Dashboard → Applications, select the active server and choose Create application. Start with the public panel title/description, the application panel channel and the private review destination.

Internal form nameA dashboard-only label such as “LSPD Application” or “Staff Application”.

Public titleThe title applicants see on the Discord application panel.

Public descriptionInstructions, expectations and any information applicants should prepare before starting.

Application panel channelThe public Discord channel where the Apply panel is published.

Private review channelThe staff-only channel where submitted application review cards can be posted.

Application log channelOptional channel for lifecycle/decision logging.

Reapplication cooldownHow long a denied/completed applicant must wait before beginning a new submission.

Max active per userLimits the number of simultaneous active submissions from one Discord user.

Reviewer rolesRoles allowed to review applications. Administrator/Manage Server users are also reviewers.

Application types / role-specific paths

One published application panel can contain up to 25 application types such as Civilian, LEO, Fire/EMS, Staff or Development. When a member clicks Apply, Submitt first asks which type they are applying for, then shows only the shared questions plus the questions assigned to that type.

Type-specific questionsAssign a question to one application type, or leave it Shared so every applicant receives it.

Approval roleOptionally add a Discord role automatically when that specific application type is approved.

Approval DMOwner-written message sent after acceptance. Normal URLs and Discord invite links are clickable.

Denial DMOwner-written message sent after denial. A failed DM never reverses the staff decision.

Decision-message variables are {user}, {username}, {server}, {application}, {role} and {reviewer}. For example, Civilian and LEO can each receive a completely different invite link and welcome message from the same Xbox application panel.

Question types

Short text

Best for concise answers such as age requirement confirmation, username or short identifier.

Paragraph

Best for motivations, scenarios, experience and other detailed written answers.

Single choice

Applicant selects one option from up to 25 configured choices.

Multiple choice

Applicant can select multiple options, with a configurable maximum number of selections.

Each question can include help text, placeholder text, required/optional behavior and validation. Text questions support minimum/maximum length. Choice questions support up to 25 options. Longer forms are automatically divided into Discord modal pages of five questions, and draft progress can be resumed during the configured draft window.

Eligibility rules

Use required roles when only certain members should be allowed to apply. If multiple required roles are selected, the applicant must have every selected role. Use blocked roles to stop members with any selected role from submitting. Typical examples include blocking already-employed members from applying again or requiring a Verified Member role.

Opening and closing applications

The form can be enabled or closed without deleting it. Closing a form preserves existing submissions and configuration while preventing new applications. This is preferable to deletion for seasonal recruitment or departments that temporarily stop hiring.

Custom review stages

Stages let your staff represent the real process instead of jumping directly from Submitted to Accepted. Examples include Initial Review, Interview Required, Interview Complete, Command Review and Final Decision. Reviewers can move applications through these stages from the dashboard/Discord review flow.

If you use a stage containing “Interview”, Submitt recognizes that as an interview-oriented stage for workflow presentation. Keep stage names clear enough that every reviewer understands what action is expected next.

Claiming applications

Reviewers can claim a submission so the team knows who is actively handling it. Claiming helps prevent duplicate work but should not be used to hide an application from other authorized reviewers. Owners can still see the complete queue and history from the dashboard.

Decision actions

Reviewers can accept, deny, waitlist, archive or reopen according to the current status. Denials can require a reason so the decision remains auditable. Reopening restores a previously finalized application when an owner or reviewer needs to continue the workflow.

Applicant profiles and history

Every submitted applicant has a server-specific profile that brings together their application history across all forms. Reviewers can press Applicant History directly on the Discord review card for an ephemeral history summary, or open the full dashboard profile from the review queue, submission page or Discord card to see previous outcomes, stages, reviewer decision notes and links back to the original submissions.

This is useful for recurring staff, faction, whitelist or development-team applications because reviewers can see whether the same Discord user was previously accepted, denied, waitlisted or reviewed on another form before making a new decision.

CSV submission export

Each application form can export its submitted application history as CSV from the form configuration page. The export includes applicant identity, status, stage, dates, claim/decision information, review actions and the answers to that form's questions.

Role automation

Each form can configure Discord role additions/removals on submission, acceptance and denial. For example, submitting an LEO application could add an Applicant role; acceptance could remove Applicant and add LEO; denial could remove Applicant and add a temporary cooldown/status role if your community uses one.

Discord role hierarchy matters

The Submitt bot role must be above every role it is expected to add or remove. If automation does not fire, check Dashboard → Setup before editing the application logic.

Publishing the application panel

Use Publish to Discord when the form is ready. If the panel was already published, the action updates the existing Discord message rather than requiring you to recreate it manually. White Label branding is resolved when the panel is rendered.

Applicant experience

01Click ApplySubmitt checks whether the form is open and whether the member satisfies eligibility/cooldown rules.

02Choose application typeIf the panel has multiple paths, the applicant selects Civilian, LEO or another configured type before questions begin.

03Complete modal pagesOnly shared questions and questions assigned to the selected type appear on the applicant's Discord screen.

04SubmitAnswers are stored and a review record is created for authorized staff.

05ReviewStaff claim, stage and decide the application while all actions remain part of the history.

06Personalized decisionConfigured role automation runs and Submitt sends the approval/denial DM written for that application type. DM delivery failure is logged without undoing the decision.

Form lifecycle and historical data

Forms with submission history should be closed rather than deleted. Submitt protects historical application records so decisions and answers remain auditable. Use descriptive internal names when creating replacements so staff can tell old and current forms apart.