Application Grouping

Applications can be grouped together so multiple related applications share a single start message. This keeps your channels clean and makes it easier for users to find what they need.

Benefits of Grouping:

• Single message contains multiple application options
• Shared color coding for visual consistency
• Cleaner channel organization
• Option to use "All in one" log channel for the entire group

Start Message Configuration

Each application group has a customizable start message that appears in Discord. This message is what users interact with to begin an application.

Message Components:

• # Channel: Select which channel the start message appears in. This is where users will find and click the application buttons.
• Color Indicator: Click the colored circle to choose a color. This color appears as a border on the message and helps identify the application group in your dashboard.
• Message Text: Write your instructions or description. Supports Discord markdown formatting like **bold text**.
• Image: Click the image icon to add a visual banner to your start message. Images make your applications more attractive and professional.

Buttons vs Dropdown Menu

Users interact with applications through either individual buttons or a dropdown menu. You can switch between these modes using the cog icon (⚙️) next to the buttons.

Button Mode (Default):

• Each application displays as its own button
• Users click directly on the application they want
• Best for 2-5 applications in a group
• Buttons can have custom labels, colors, and emojis
• Button styles: Primary, Secondary, Success, Danger

Dropdown Mode:

• All applications appear in a single select menu
• More compact layout for 5+ applications
• Users select from the dropdown to begin
• Better for servers with many application types

Sending the Message to Discord

After configuring your start message, use the arrow button (→) on the right side to send it to Discord.

How It Works:

• If this is the first time sending, the bot creates a new message in the selected channel
• If the message already exists, the bot updates it with your changes
• If the previous message was deleted, a new one is created
• The message will show a loading indicator while being sent

Log Channels Configuration

Log channels are where application submissions are sent for staff review. You have flexible options for organizing these logs.

Group Log Channel (For groups with 2+ applications):

When you have multiple applications grouped together, you can enable "All in the same" mode. This sends all applications from the group to a single log channel, keeping everything organized in one place.

• Toggle "All in the same" to enable group logging
• Select a channel from the dropdown
• When enabled, individual log channels are dimmed/disabled
• All applications in the group will post to this shared channel

Individual Log Channels:

Each application can have its own dedicated log channel. This is useful when different staff teams handle different application types.

• Select a channel for each application in the list
• Applications show their name next to the channel selector
• Each log channel can have its own ping settings

Thread Ping Notifications

When an application is submitted, it creates a thread in your log channel. You can configure which roles get pinged (mentioned) in that thread.

How Thread Pings Work:

• Click the + button next to "Ping" to add roles
• Selected roles will be mentioned when a new application arrives
• Pinged users will see the thread appear in their channel list
• By default, threads are "hidden" unless you're pinged or manually open them
• Multiple roles can be added for each application
• Click the X on a role to remove it from pings

Visual Customization

Message Text Formatting:

Your start message supports Discord markdown:

• **bold text** for emphasis
• *italic text* for subtle highlights
• __underlined__ for underlining
• `code` for inline code

Adding Images:

Click the image placeholder to open the image upload modal where you can:

• Upload an image from your computer
• Enter an image URL
• Preview how it will look
• Remove the image by clicking the X

Color Coding:

The color you choose appears as a border on your start message in Discord and helps you quickly identify different application groups in the dashboard. Click the colored circle to open a color picker.

Common Setup Examples

Example 1: Staff Applications

Setup: Single application, dedicated log channel, ping @moderators role
Best for: Servers recruiting staff members

Example 2: Multiple Departments

Setup: Group 3-5 department applications, use dropdown menu, shared log channel with different pings per department
Best for: Large communities with multiple teams (Support, Events, Moderation)

Example 3: Guild Recruitment

Setup: Two applications (Main roster + Trial), button mode with custom styling, separate log channels for each tier
Best for: Gaming guilds with multiple membership levels

🗨️ DM Applications (Conversational)

📝 Modal Tickets (Form Submission)

🎯 Which Type Should You Use?

🔧 Troubleshooting

✅ Best Practices

🔄 Switching Between Types

💡 Real-World Examples

🔗 Integration with Other Features

🎓 Advanced Configuration

📊 Performance & Analytics

❓ Frequently Asked Questions

📝 Summary

Both types integrate with all AppBot features (automation, Google Sheets, statistics, etc.). Choose based on your specific needs, or run both types for different purposes in the same server.

🔘 Button Basics

🎯 Single-Select vs Multi-Select

📋 Dropdown Menus

💡 Real-World Examples

🔧 Troubleshooting

Understanding the Three Stages

Stage-Specific Features

⚪ Submit Stage (Automatic)

• When: Immediately after user completes application
• Purpose: Initial processing, mark as pending, create thread, notify staff
• Unique Settings:
  • Private Thread toggle (adds applicant to private thread)
  • Disable Threads (post as regular message instead)
  • Disable Log Msg (suppress default accept/deny log messages)
  • Dynamic Ping (auto-mention staff based on applicant's button selections)
  • Thread message buttons for staff role selection
• Role Behavior: Button-selected roles are stored but not applied yet

🟢 Accept Stage (Manual)

• When: Staff clicks Accept button
• Purpose: Grant full access, assign all privileges, welcome the member
• Unique Settings:
  • Staff comment modal (required or optional internal note)
  • Custom DM field (staff can add personal message)
  • Role-specific messages (send different DMs per role selected)
• Role Behavior: Button-selected roles are applied (from questions + thread messages + Steam)

🔴 Deny Stage (Manual)

• When: Staff clicks Deny button
• Purpose: Remove pending status, optionally inform applicant, close application
• Unique Settings:
  • Staff comment modal (same as Accept)
  • Custom DM field (same as Accept)
• Role Behavior: Button-selected roles are ignored completely

Submit-Only Settings

These configuration options only appear in the Submit stage:

Thread Behavior Toggles

Private Thread

• Enabled: Creates a private thread. Only mentioned users and roles can access it. The applicant is automatically added.
• Disabled: Creates a public thread. Inherits permissions from parent channel. Applicant must be pinged or manually join to see it.
• Use case: Enable when you want the applicant involved in the review discussion
• Tip: Combine with "Disable Log Msg" to use the start message channel as the log channel

Disable Threads

• Enabled: Applications post as regular messages in the log channel instead of creating threads
• Best for: Servers that hit Discord's active thread limits or prefer traditional workflows
• Limitation: Thread-specific features like like edit Thread Name won't function

Disable Log Msg

• Enabled: Suppresses the default system message when apps are accepted or denied
• Use case: Cleaner workflows when you have custom channel messages configured
• Advanced: With private threads + disabled logs, you can use the same channel for start messages and applications

Dynamic Staff Pings

Automatically mention staff roles in the thread based on which buttons the applicant selected during their application.

How It Works:

• Enable "Dynamic Ping" toggle in Submit → Send Message settings
• For each button in your application questions, assign a staff role to ping
• When applicant selects a button, the corresponding staff role is mentioned in the thread
• Multiple selections = multiple role pings
• Pings appear in the custom thread message, not as separate notifications

Setup Example:

Question: "Which department are you applying for?"
Buttons: Engineering, Marketing, Support
Dynamic Ping Config:
• Engineering button → Pings @Engineering-Leads
• Marketing button → Pings @Marketing-Managers
• Support button → Pings @Support-Staff

Result: Applicant selects "Engineering" → Thread message includes "@Engineering-Leads New application!"

Thread Message Buttons (Staff Role Selection)

Add interactive buttons to the thread message that staff can click to select roles for the applicant.

Button Configuration:

• Configure in Submit → Send Message → Add Buttons
• Assign a role to each button
• Staff click buttons during review to prepare role assignments
• Roles are only applied on Accept, not immediately when clicked
• Buttons toggle on/off (click again to deselect)
• Current selections shown in an embed below the buttons

Button vs Question Buttons:

• Question buttons: Applicant clicks during application
• Thread message buttons: Staff clicks during review
• Both types are stored and applied together on Accept
• Both types are ignored on Deny

Permissions:

• Only users with configured Staff Roles or Administrator can click role buttons
• Non-staff see "Not enough permissions" error
• Prevents applicants or other members from manipulating role assignments

Staff Comment Modal (Accept & Deny)

When staff click Accept or Deny, a popup modal appears with two text fields for comments and custom messages.

Internal Staff Log Comment

• First field in the modal popup
• Can be set as Required or Optional in dashboard
• Posted as an embed in the application thread
• Visible only to staff with thread access
• Documents decision reasoning for record-keeping
• Maximum 3000 characters

Customization Options:

• Placeholder text: Gray hint text shown before staff types (e.g., "Explain your decision")
• Default value: Pre-filled text that appears automatically (e.g., "Meets all requirements")
• Required toggle: Force staff to enter a reason (Accept/Deny only, not Submit)

Direct Message to Applicant

• Second field in the modal popup
• Always optional (cannot be required)
• Sent to applicant via DM along with your configured messages
• Allows staff to add personal notes or specific instructions
• Also posted in thread as an embed for transparency
• Maximum 3000 characters

Customization Options:

• Placeholder text: Guide staff on what to write (e.g., "Optional message to applicant")
• Default value: Common messages like "Welcome aboard!" or "Feel free to reapply in 30 days"

How Comments Appear

• In Thread: Two separate embeds posted - one for internal comment (if provided), one for DM preview (if provided)
• Accept embeds: Green color
• Deny embeds: Red color
• Author: Shows staff member's username and avatar
• Visibility: Internal comments only visible to thread members; DM content also sent to applicant

Shared Actions (All Stages)

The following features are available in Submit, Accept, and Deny stages with identical functionality:

Add Role

Assign roles to the applicant when the stage executes.

Configuration:

• Click the + button to open role selector
• Choose from dropdown of available server roles
• Multiple roles can be selected

Behavior by Stage:

• Submit: Common to add @Pending or @Applicant role
• Accept: Add @Member, @Recruit, or tier roles
• Deny: Typically left empty, or add @Denied for tracking

Remove Role

Remove roles from the applicant when the stage executes.

Configuration:

• Click the + button to open role selector
• Choose which roles to remove
• Executes simultaneously with "Add Role" for efficiency
• Only removes roles the user actually has (safe to list roles they might not have)

Behavior by Stage:

• Submit: Remove @Guest or @Unverified when applying
• Accept: Remove @Pending, @Applicant, or @Trial
• Deny: Remove @Pending, @Applicant

Edit Nickname

Change the applicant's server nickname to match your naming conventions.

Configuration:

• Click the pfp icon to open nickname editor modal
• Enter static text or use dynamic placeholders
• Leave empty to keep current nickname
• Maximum 32 characters (Discord limit)

Available Placeholders:

• {username} → Discord username
• {globalname} → Global display name
• {nickname} → Current server nickname
• {answer1}, {answer2} → Specific answers
• {app_count} → Application counter number
• {acceptor} → Staff name (Accept/Deny only)

Common Patterns:

• Submit: [PENDING] {username}
• Accept: [MEMBER] {username} or {answer1} | {username}
• Deny: Usually left empty to preserve original nickname

Edit Thread Name

Customize the name of the application thread to organize and identify applications easily.

Configuration:

• Click the thread edit icon to open the modal
• Enter static text or use dynamic placeholders
• Maximum 100 characters (Discord limit)

Default Thread Names:

• Submit: 📋 username (or 📋 👤❔ if Hide Stats enabled)
• Accept: ✅ username 🛂 staffname
• Deny: ⛔ username 🛂 staffname

Available Placeholders:

Same as Edit Nickname, plus:

• {acceptor} → Staff member's name (Accept/Deny only)
• All answer and question placeholders
• Custom emojis can be copy-pasted from the modal's emoji picker

Advanced Customization:

The modal includes an "Advanced" section with conditional replacements based on answers or button selections:

For Button Questions:

• Each button can have a custom replacement text
• When that button is selected, use {rule1} to insert the custom text
• Example: Tank button → replacement "TANK" → Thread name: {rule1} Application - {username} becomes "TANK Application - JohnDoe"

For Text Questions:

• Match Text: Enter words or JavaScript regex to search for in the answer
• Replace Text: Text to use when match is found
• Use {rule1}, {rule2} etc. in your template to insert replacements
• Example: If answer contains "yes" → replace with "APPROVED" → Thread name uses {rule1}

Send Message

Post custom embeds with text, images, and optional buttons to the application thread or a different channel.

Message Builder Components:

• Enable toggle: Turn message on/off without deleting configuration
• Text field: Main message content, supports Discord markdown and placeholders
• Picture URL: Large banner image (bottom of embed), must be direct image link
• Thumbnail URL: Small corner image (top-right), must be direct image link
• Channel selector: Defaults to thread, can send to any channel

Available Placeholders:

• {user} → Mentions the applicant
• {username}, {globalname}, {nickname} → Name variants
• {thread} or {app_link} → Link to application
• {acceptor} or {staffName} → Staff member (Accept/Deny)
• {guildname} → Server name
• {appname} → Application name
• {app_button} → Start button label
• {answer1}, {answer2} → Specific answers
• {question1}, {question2} → Question text
• {here} or @here → Pings @here
• {<@&roleId>} → Pings specific role (e.g., {<@&123456789>})

Message Behavior:

• Thread messages: Posted in the application thread
• Channel messages: Select different channel to post elsewhere
• Pings: User mentions, role mentions, and @here appear as content (not in embed) to trigger notifications
• Videos/YouTube: Links post as separate message before the embed
• Multiple messages: You can configure multiple Send Message actions per stage

Send Command

Execute a custom message in a specific channel, useful for cross-posting or triggering other bots.

Configuration:

• Click the command icon (terminal symbol) to open settings
• Enable toggle to activate
• Select target channel from dropdown
• Enter command or message text
• Supports all placeholders (same as Send Message)

Use Cases:

• Cross-posting: "New {username} application in {thread}" to #staff-notifications
• Public announcements: "Welcome {user} to the team!" in #welcome (Accept only)
• External logging: Post to channels monitored by other bots for analytics
• Trigger workflows: Some bots respond to specific message patterns

Execution Timing:

• Executes after role changes and DMs
• Executes after "Send Message" actions
• Multiple commands can be configured (though only one field in UI - use Send Message for multiple channels)

Schedules (Premium)

Delay execution of actions to occur after a specified number of hours.

Configuration:

• Click the timer icon to open schedule settings
• Enter hours until execution (e.g., 24, 48, 168)
• Configure which actions should be scheduled
• Scheduled actions: role additions, role removals, messages
• Requires active premium subscription

Schedule Behavior by Stage:

• If applicant leaves server before execution, schedule is cancelled
• Submit schedule: Executes X hours after submission
• Accept schedule: Executes X hours after acceptance, overwrites Submit schedule if present
• Deny schedule: Executes X hours after denial, overwrites Submit schedule if present

Common Use Cases:

• Trial periods: Submit adds @Trial, schedule removes @Trial and adds @Full Member after 168 hours (7 days)
• Temporary access: Accept adds @Event Access, schedule removes it after 48 hours
• Delayed onboarding: Accept schedules "Welcome to advanced training!" DM 24 hours later
• Reminder messages: Submit schedules "Your application is still pending" after 72 hours

Forum Tags

Automatically add or remove tags when your log channel is a Forum channel.

Configuration:

• Click the tag icon to open tag manager
• Only functional when log channel type is "Forum"
• Grayed out when log channel is not a forum
• Add up to 5 tags total per thread (Discord limit)
• Select tags to add and/or remove

Tag Behavior:

• Add tags: Appends new tags to existing ones
• Remove tags: Removes specified tags from thread
• Combination: Can add and remove in same operation (e.g., remove "Pending", add "Approved")
• Limit: Discord enforces 5 tags maximum per thread
• Timing: Tags update when thread is renamed and archived (Accept/Deny), or when created (Submit)

Common Tag Workflows:

• Submit: Add "Pending", "New", department tag
• Accept: Remove "Pending", add "Accepted", "Active"
• Deny: Remove "Pending", add "Denied", "Closed"
• Department tracking: Add department/role tags based on selection
• Priority: Add "Urgent", "Standard", "Low Priority" tags

Accept-Only Features

These features are exclusive to the Accept stage and don't appear in Submit or Deny:

Role-Specific Messages

Send custom DMs or channel messages based on which roles the applicant selected via buttons during their application.

How It Works:

• Located in the "Custom Role Message" section at bottom of Accept settings
• Lists all roles that have been assigned to buttons in your application questions
• Click on the available role button to configure its custom message
• Each role can have unique text, embeds, images, and channel destinations
• Messages send in addition to standard Accept messages

Message Configuration:

• Enable toggle: Turn role message on/off
• DM or Channel: Send to applicant's DM or post in a channel
• Text field: Custom message text with placeholder support
• Picture/Thumbnail: Add role-specific images
• Channel selector: Choose channel for role announcements

Use Cases:

• Role-specific onboarding: Tank role → "Read tanking guide at [link]"
• Department welcome: Engineering role → "Join #engineering-onboarding"
• Team assignments: Raid Team A → "Your raid schedule is Tuesday/Thursday 8pm"
• Conditional instructions: Officer role → "Review officer guidelines in #officer-info"

Message Delivery Order:

1. Staff modal comment (internal log)
2. Staff modal DM field (if provided)
3. Standard Accept DM (if configured)
4. Role-specific DMs (one per role selected)
5. Channel messages (standard + role-specific)

Button Role Assignment

This is not a separate feature but a critical behavior unique to Accept:

Role Calculation on Accept:

1. Start with applicant's current roles
2. Remove roles from "Remove Role" list
3. Add roles from "Add Role" list
4. Add roles from question buttons (applicant's selections)
5. Add roles from thread message buttons (staff's selections)
6. Add Steam-verified roles (if Steam integration enabled)
7. Remove duplicates
8. Filter out admin-permission roles
9. Apply all changes in single operation

Why This Matters:

• Accept is the only stage where button roles are actually assigned
• Submit stores the selections but doesn't apply them
• Deny completely ignores button selections
• This ensures denied applicants never receive privilege-granting roles

Complete Workflow Examples

Example 1: Simple Staff Recruitment

Submit Configuration:

• Add Role: @Applicant
• Remove Role: @Member
• Thread Name: 📋 Staff App - {username}
• Send Message: "Thank you for applying! Staff will review your application soon."

Accept Configuration:

• Add Role: @Staff
• Remove Role: @Applicant
• Nickname: [STAFF] {username}
• Thread Name: ✅ {username} → {acceptor}
• Send Message (DM): "Congratulations! Welcome to the staff team. Please read #staff-guide for your responsibilities."
• Send Command (#announcements): "Please welcome our newest staff member, {user}! 🎉"

Deny Configuration:

• Remove Role: @Applicant
• Thread Name: ⛔ {username}
• Send Message (DM): "Thank you for your interest in our staff team. While we cannot offer you a position at this time, we encourage you to remain active in the community and reapply in the future."

Example 2: Guild Recruitment with Trial Period

Submit Configuration:

• Add Role: @Applicant
• Remove Role: @Guest
• Private Thread: Enabled
• Thread Name: 🆕 {answer1} - {username} (if answer1 is class/role)
• Send Message: Buttons for staff to select additional roles (Main Roster, Alt Roster, Social)
• Dynamic Ping: Enabled (pings recruitment officers based on class selection)

Accept Configuration:

• Add Role: @Trial Member
• Remove Role: @Applicant
• Nickname: [TRIAL] {username}
• Thread Name: ✅ Trial - {username}
• Send Message (DM): "Welcome to the guild! Your trial period is 7 days. Join #trial-info for guidelines and schedules."
• Send Command (#guild-chat): "Welcome {user} as a trial member! Help them feel at home 🏠"
• Schedule (168 hours): Remove @Trial Member, Add @Full Member, Send DM "Congratulations on completing your trial! You're now a full member."
• Role Messages:
  • Main Roster role → "You're on our main roster! Raids are Monday/Wednesday 8pm"
  • Alt Roster role → "You're on alt roster. We'll call you for fill-ins!"

Deny Configuration:

• Remove Role: @Applicant
• Thread Name: ⛔ {username}
• Send Message (DM): "Thank you for your application. We're currently at capacity for {answer1} players, but we encourage you to reapply in 30 days."

Example 3: Multi-Department Company

Submit Configuration:

• Add Role: @Applicant
• Thread Name: 📋 {answer1} - {username} (answer1 is department)
• Send Message: "Your application has been received. Department leads have been notified."
• Dynamic Ping: Enabled
  • Engineering button → @Engineering-Leads
  • Marketing button → @Marketing-Managers
  • Support button → @Support-Directors
• Thread Buttons: "Schedule Interview", "Request Additional Info", "Fast Track"

Accept Configuration:

• Add Role: @Employee
• Remove Role: @Applicant
• Button roles assigned automatically (Engineering, Marketing, Support - from questions)
• Thread Name: ✅ {rule1} - {username} (rule1 = department abbreviation)
• Send Message (DM): "Congratulations! Welcome to the team. Your onboarding coordinator will contact you within 24 hours."
• Send Command (#team-announcements): "Please welcome {user} to the {answer1} team! 🎊"
• Role Messages:
  • Engineering → DM: "Join #engineering-onboarding and complete the setup guide" + Channel message in #engineering
  • Marketing → DM: "Your first project brief is in #marketing-projects" + Channel message in #marketing
  • Support → DM: "Training starts Monday in #support-training" + Channel message in #support

Deny Configuration:

• Remove Role: @Applicant
• Thread Name: ⛔ {username} - {answer1}
• Send Message (DM): "Thank you for your interest in {answer1}. We'll keep your information on file for future openings."

Staff Permissions

Define which roles have permission to manage applications. These settings control access to administrative actions like accepting, denying, and viewing applications.

Staff Roles

Assign roles that can perform staff actions on applications.

What Staff Can Do:

• Accept applications
• Deny applications
• Send direct messages to applicants
• Open tickets for discussion
• Click thread message buttons to select roles
• View application threads and answers

Configuration:

• Click the + button to add staff roles
• Select multiple roles from the dropdown
• Click X on a role badge to remove it
• If no roles are added, only Administrator permission users can manage applications
• Users with Administrator permission always have staff access, regardless of role list

Enable/Disable Application Roles

Assign roles that can toggle applications on or off using the /info command.

What This Controls:

• Users with these roles can use /info to see application status
• They can enable or disable specific applications temporarily
• Useful for staff who manage recruitment without needing full staff permissions
• Does not grant access to Accept/Deny actions

Configuration:

• Click the + button to add roles
• Multiple roles can be selected
• Separate from Staff Roles (can overlap if needed)
• If empty, only Administrators can toggle applications

Applicant Requirements

Set criteria that users must meet before they can start an application. The bot checks these requirements when a user clicks the start button and blocks access if criteria aren't met.

Required Roles to Apply

Users must have specific roles to access the application.

Configuration:

• Click the + button to add required roles
• Multiple roles can be added
• Toggle between "any" or "all" mode when 2+ roles are selected
• If empty, no role requirements (anyone can apply)

Any vs All Mode:

• Any mode (default): User needs at least ONE of the listed roles
• All mode: User must have EVERY listed role
• Mode toggle only appears when 2 or more roles are added
• Click the "any"/"all" button to switch modes

Example Scenarios:

Scenario 1 - Department Applications:
Required Roles: @Engineering, @Marketing, @Support (ANY mode)
Result: Members of any department can apply

Scenario 2 - Senior Staff:
Required Roles: @Staff, @Verified (ALL mode)
Result: Only verified staff members can apply

Scenario 3 - Open Recruitment:
Required Roles: (empty)
Result: Anyone can apply

Prevent Roles from Applying

Block users with specific roles from accessing the application.

Configuration:

• Click the + button to add blocked roles
• Multiple roles can be added
• Toggle between "any" or "all" mode when 2+ roles are selected
• If empty, no roles are blocked

Any vs All Mode:

• Any mode (default): User is blocked if they have ANY of the listed roles
• All mode: User is only blocked if they have ALL listed roles
• Mode toggle appears when 2 or more roles are added

Common Use Cases:

• Existing members: Prevent @Member role from applying (for new member recruitment)
• Banned users: Prevent @Blacklisted from re-applying
• Recent denials: Prevent @Recently-Denied role (set by Deny action)
• Backlog control: Prevent @Max-Apps-Reached to limit spam (Premium feature)

Required Membership Time

Set a minimum server membership duration before users can apply.

Configuration:

• Toggle to enable/disable the requirement
• Set days (0-999)
• Set hours (0-23)
• Both fields are additive (e.g., 7 days + 12 hours = 7.5 days total)
• Bot calculates from user's join date to current time

How It Works:

• When user clicks start button, bot checks their Discord join timestamp
• Calculates elapsed time since joining the server
• If elapsed time is less than required, user sees error message
• Error message tells them how much longer they must wait

Example Requirements:

• New server protection: 7 days + 0 hours (prevent brand new accounts)
• Observation period: 30 days (ensure active participation first)
• Quick screening: 0 days + 12 hours (basic delay)
• Long-term members only: 90 days (veteran applications)

Re-Application Cooldown

Prevent users from submitting the same application repeatedly within a short time period.

Configuration:

• Toggle to enable/disable cooldown
• Set days (0-999)
• Set hours (0-23)
• Minimum cooldown: 15 minutes (0 days + 0 hours defaults to 15 minutes)
• Cooldown starts from most recent submission time, not acceptance/denial

How It Works:

• When user submits an application, timestamp is recorded
• If user tries to start same application again before cooldown expires, access is blocked
• Error message tells them how much time remains
• Cooldown is per-application (user can apply to different applications)
• Cooldown persists even if previous application was accepted/denied

Cooldown Behavior:

• Started but not submitted: No cooldown triggered
• Submitted (pending): Cooldown starts
• Accepted: Cooldown remains active
• Denied: Cooldown remains active
• Multiple submissions: Cooldown resets each time user submits

Common Cooldown Periods:

• Quick retry: 1 day (for low-stakes applications)
• Standard: 7 days (balanced approach)
• Long cooldown: 30 days (high-stakes positions)
• Seasonal: 90 days (quarterly recruitment cycles)

Max Applications Role Assignment (Premium)

Automatically assign a role to users after they submit a specific number of pending applications.

How It Works:

• Tracks how many times a user has submitted this specific application
• When user reaches the configured submission number (e.g., 2nd, 3rd, 5th), bot assigns role(s)
• Only counts submitted (pending) applications - accepted and denied apps don't count
• Role persists until manually removed
• Typically used with "Prevent Roles" to stop users from applying repeatedly

Configuration:

• Appears below cooldown settings when cooldown is enabled
• Set "Submission No." (minimum 2, defaults to 2)
• Click + to add role(s) to assign
• Multiple roles can be added
• Common pattern: Create a @Max-Apps-Reached role and add it to "Prevent Roles"

Example Workflow:

Goal: Prevent users from submitting more than 2 pending applications

Setup:
1. Create role: @Too-Many-Apps
2. Enable re-application cooldown (any duration)
3. Set "Submission No." to 2
4. Add @Too-Many-Apps to the role list
5. In "Prevent Roles", add @Too-Many-Apps

Result:
• User submits 1st app → Pending, no role assigned
• User submits 2nd app → Pending, @Too-Many-Apps assigned
• User tries 3rd app → Blocked by "Prevent Roles"
• Staff accepts/denies user's apps → User can apply again (manually remove @Too-Many-Apps or use Deny action to remove it)

Counter Behavior:

• Counts: Only submitted applications in "pending" status
• Doesn't count: Started but not submitted, accepted apps, denied apps
• Resets: Never automatically resets (manual intervention required)
• Per-application: Counter is specific to each application type

Permission Check Flow

Understanding the order of checks helps you design effective permission systems.

When User Clicks Start Button:

1. Required Roles Check: Does user have required role(s)? (If configured)
   • ANY mode: User must have at least one role
   • ALL mode: User must have every role
   • If fails: "You need [role name] to apply"
2. Prevent Roles Check: Does user have blocked role(s)? (If configured)
   • ANY mode: User blocked if they have any role
   • ALL mode: User blocked only if they have all roles
   • If fails: "You cannot apply with [role name]"
3. Membership Time Check: Has user been member long enough? (If enabled)
   • Calculates days + hours since server join
   • If fails: "You must be a member for [X] more time"
4. Cooldown Check: Has enough time passed since last submission? (If enabled)
   • Checks timestamp of most recent submission
   • If fails: "You can apply again in [X] time"
5. DM Access Check: Can bot send DMs to user? (For non-ticket applications)
   • If fails: "Please enable DMs from server members"

When Staff Tries to Accept/Deny:

1. Staff Role Check: Does user have staff role or Administrator permission?
   • If fails: "Not enough permissions"
2. Application Status Check: Is application still pending?
   • If fails: "Application already processed"
3. Member Fetch Check: Is applicant still in server?
   • If fails: "User left guild"

Common Permission Configurations

Example 1: Open Recruitment

Goal: Anyone can apply, but with spam protection
Setup:
• Required Roles: (empty)
• Prevent Roles: (empty)
• Membership Time: 1 day
• Cooldown: 3 days
Best for: Growing servers, public recruitment

Example 2: Member Progression

Goal: Only verified members can apply for advanced roles
Setup:
• Required Roles: @Verified (must have)
• Prevent Roles: @Staff (already staff can't apply)
• Membership Time: 30 days
• Cooldown: 14 days
Best for: Staff applications, leadership roles

Example 3: Controlled Recruitment

Goal: Limit applications to reduce backlog
Setup:
• Required Roles: @Eligible (manually assigned)
• Prevent Roles: @Too-Many-Apps
• Membership Time: 7 days
• Cooldown: 7 days
• Max Apps (Premium): 2 submissions → add @Too-Many-Apps
Best for: High-volume servers, selective recruitment

Example 4: Department Applications

Goal: Current employees can apply for department transfers
Setup:
• Required Roles: @Employee (must have)
• Prevent Roles: @Engineering, @Marketing, @Support (ANY mode - can't apply if already in a department)
• Membership Time: (disabled)
• Cooldown: 30 days (prevent frequent transfers)
Best for: Internal transfers, department changes

Linked Accounts Verification

Check which external platforms the applicant has linked to their Discord account.

What Gets Checked

When enabled, the bot can see all platforms linked to the applicant's Discord account, including:

• YouTube: Linked YouTube channels
• Twitch: Twitch accounts
• Reddit: Reddit usernames
• Twitter/X: Twitter accounts
• Steam: Steam profiles
• Spotify: Spotify accounts
• Xbox: Xbox gamertags
• PlayStation: PSN IDs
• And any other platforms Discord supports

How It Works

1. User clicks application start button
2. Bot redirects to Discord OAuth2 authorization page
3. User grants "View your connections" permission
4. Bot retrieves list of linked platforms
5. Application begins normally

Special Behavior: Steam Comparison

If the applicant has Steam linked to Discord AND your application includes a Steam profile question:

• Bot automatically compares the linked Steam account against the Steam URL answer
• If they don't match, applicant may be flagged for verification
• Helps detect fake Steam profiles or incorrect submissions
• Appears in application data for staff review

Configuration

• Toggle "Linked Accounts" to enable/disable
• When enabled, applicants must authorize OAuth2
• Linked accounts data is stored with application for staff review
• No additional setup required beyond enabling the toggle

Discord Server Membership Verification

Check if the applicant is a member of specific Discord servers before allowing them to apply.

What Gets Checked

When enabled, the bot verifies if the applicant is a member of any servers you specify. This is useful for:

• Cross-server requirements (e.g., must be in partner server)
• Verification servers (e.g., must be verified elsewhere first)
• Network requirements (e.g., gaming network with multiple servers)
• Alliance requirements (e.g., must be in allied guild)

How It Works

1. You add server IDs to the list (explained below)
2. User clicks application start button
3. Bot redirects to Discord OAuth2 authorization page
4. User grants "View your servers" permission
5. Bot checks if user is member of ANY of the listed servers
6. If user is in at least one listed server, application proceeds
7. If user is in none of the listed servers, application is blocked

Adding Server IDs

Method 1: Manual Entry

1. Click the "+ Server ID" button to add a new field
2. Enter the Discord server ID (18-19 digit number)
3. Optionally add a note/label in the second field (for your reference)
4. Click X to remove a server from the list
5. Add as many servers as needed

Method 2: Quick Select (if available)

• If the dropdown appears, it shows servers where the bot is also present
• Click a server name from the list to auto-fill its ID
• Use the search box to filter servers by name
• Much faster than manually copying IDs

Getting Server IDs

To manually find a Discord server ID:

1. Open Discord (desktop or browser, not mobile)
2. Click your profile picture → User Settings (⚙️ gear icon)
3. Go to "Advanced" tab
4. Enable "Developer Mode"
5. Close settings
6. Right-click on any server icon in your server list
7. Click "Copy Server ID" at the bottom of the menu
8. Paste the ID into the dashboard field

Configuration Options

• Toggle: Enable/disable server verification
• Server IDs: List of servers to check (accepts multiple)
• Optional Notes: Add labels like "Partner Server" or "Verification Hub" for your reference
• Search: Filter your server list when you have many entries

Verification Logic

• ANY match: User must be in at least ONE of the listed servers (not all)
• No "ALL" mode: Cannot require membership in multiple servers simultaneously
• Empty list: If no servers are added, this check is skipped even if toggle is enabled
• Private servers: Bot can verify membership even if user left or server is private

OAuth2 Authorization Flow

Understanding the authorization process helps you guide applicants through the experience.

What Users See

1. Click start button: Instead of opening DMs or modal, redirected to Discord website
2. Authorization page: Discord shows official authorization prompt with:
   • Bot name and avatar
   • Requested permissions ("connections", "guilds")
   • "Authorize" and "Cancel" buttons
3. Grant permission: User clicks "Authorize"
4. Redirect back: Discord redirects user back to your application
5. Application starts: Bot has verified data, application proceeds normally

If User Declines Authorization

• Application cannot proceed
• User sees error message explaining authorization is required
• User can try again by clicking start button again
• No data is collected if user declines

Data Storage

• Linked accounts: List of platform names stored with application (e.g., "Steam, YouTube, Reddit")
• Server memberships: List of server IDs user is member of (only from your configured list)
• Not stored: Platform usernames, profile URLs, or full guild list
• Retention: Data follows your application data retention settings

Combining Discord Integration with Other Requirements

Discord Integration works alongside other permission systems for layered verification.

Check Order

1. Role requirements (from Permissions tab)
2. Prevent roles (from Permissions tab)
3. Membership time (from Permissions tab)
4. Cooldown (from Permissions tab)
5. Discord OAuth2 authorization (if enabled)
6. Linked accounts check (if enabled)
7. Server membership check (if enabled)
8. Application starts

Example: Multi-Layer Verification

Goal: Highly secure staff recruitment
Setup:
• Permissions → Required Roles: @Verified
• Permissions → Membership Time: 30 days
• Discord → Linked Accounts: Enabled
• Discord → Server Membership: Must be in verification server

Result:
Applicant must: 1. Have @Verified role
2. Be server member for 30+ days
3. Authorize Discord OAuth2
4. Be member of verification server
Only then can they start the application

Viewing OAuth2 Data in Applications

When staff review applications, OAuth2 verification results appear in the application thread.

What Staff See

• Linked Accounts: List of platforms (e.g., "Steam, YouTube, Twitch")
• Server Memberships: "✓ Verified in required servers" or list of matched servers
• Steam Comparison: If Steam is linked and answered, shows match status
• Missing Data: If user has no linked accounts, shows "None"

Using OAuth2 Data for Decisions

• Verify claimed social media accounts actually exist
• Confirm platform usernames match Discord identity
• Check if applicant meets partnership requirements
• Detect potential fake accounts (no linked platforms = suspicious)

How Steam Integration Works

Data Flow

1. Applicant submits application with Steam profile URL answer
2. Bot extracts Steam ID from the provided URL
3. Bot queries Steam API for public profile data
4. Bot checks game library, playtime, and recent activity
5. Bot compares data against your configured criteria
6. Matching roles are assigned automatically on Accept

What Data Is Retrieved

• Game Library: List of owned games
• Total Hours: All-time playtime per game
• Recent Activity: Hours played in last 2 weeks per game
• Profile Status: Public/Private status

Configuring Steam Requirements

Set up game-based role assignments using the Steam settings table. Each game can have multiple criteria (ownership, total hours, recent activity) with different role rewards.

Adding Games

Step 1: Search for Game

• Click the "+ add game" button
• Search modal opens with search bar
• Type game name (minimum 2 characters)
• Results appear as you type, pulled from Steam store
• Click a game from results to add it

Step 2: Configure Game Criteria

Once added, each game shows as a row with the following options:

Game Ownership

Assign a role simply for owning the game in their library.

Configuration:

• Game row shows game thumbnail/icon
• "in Library" indicator
• Click + button to select role
• Selected role appears next to the game
• Click X on role to remove

Use Cases:

• Game verification: Prove they own your game (e.g., @CS2-Player)
• Genre tagging: Own RPG game → @RPG-Enthusiast
• Franchise recognition: Own Dark Souls → @Souls-Veteran

Total Hours Played

Assign roles based on all-time playtime in a specific game.

Configuration:

• Click "Tot Hours" button under the game
• Enter minimum hours (left field)
• Enter maximum hours (right field) - optional
• Click + to select role
• Add multiple hour ranges for the same game with different roles
• Click X to remove a hour requirement row

Hour Range Logic:

• Min only: 100 (no max) = 100+ hours required
• Min and Max: 100 ↔ 500 = between 100-500 hours
• Max only: (no min) ↔ 50 = less than 50 hours
• Multiple ranges: Create tiers (0-100 = Novice, 100-500 = Experienced, 500+ = Expert)

Example Setup:

Game: Counter-Strike 2
Tier 1: 0 ↔ 500 hours → @CS2-Beginner
Tier 2: 500 ↔ 2000 hours → @CS2-Intermediate
Tier 3: 2000+ hours → @CS2-Expert

Result: Players automatically get tier role based on playtime

Last 2 Weeks Activity

Assign roles based on recent playtime (rolling 2-week window).

Configuration:

• "last 2 weeks" row appears under each game automatically
• Enter minimum hours (left field)
• Enter maximum hours (right field) - optional
• Click + to select role
• Only one "last 2 weeks" requirement per game
• Cannot add multiple rows like Total Hours

Use Cases:

• Activity verification: 10+ hours last 2 weeks → @Active-Player
• Recruitment requirements: Must have played recently to join raid team
• Season participation: Active during current season
• Inactivity detection: 0 hours last 2 weeks → (don't assign active role)

Example Setup:

Game: Destiny 2
Ownership: In library → @D2-Player
Total Hours: 500+ → @D2-Veteran
Last 2 Weeks: 20+ hours → @D2-Active

Result: Active veterans get all 3 roles, inactive veterans get only first 2

Managing Steam Games

Editing Games

• Change game: Click the game thumbnail to open search modal and select different game
• Add hours tiers: Click "Tot Hours" button to add another hour range row
• Remove hour tier: Click X on the right side of the hour range row
• Remove game entirely: Click X on the far right of the game row (top-level)

Role Management

• Add role: Click + button next to criteria
• Change role: Remove existing role (X) then add new one (+)
• Remove role: Click X on the role badge
• Missing roles: If role is deleted from Discord, shows "Delete me (ID: ...)" - click X to clean up

Adding Multiple Games

• Click "+ add game" for each additional game
• No limit on number of games (within reason)
• Each game appears as separate section in the table
• Games are checked sequentially - all matching criteria assign roles

When Steam Roles Are Assigned

Assignment Timing

Steam roles are assigned on Accept only, not on Submit or Deny.

Process Flow:

1. User submits application with Steam URL
2. Bot validates Steam profile is public and accessible
3. Bot retrieves game data from Steam API
4. Bot evaluates all configured criteria
5. Matching roles are stored in database
6. When staff clicks Accept, Steam roles are assigned along with other roles
7. If staff clicks Deny, no Steam roles are assigned

Final Role Calculation on Accept

Steam roles are added to the total role calculation:

Final Roles =
Current roles
- Remove roles (from Accept settings)
+ Add roles (from Accept settings)
+ Button-selected roles (from questions)
+ Thread button roles (from staff)
+ Steam roles (from game criteria)

Steam Profile Requirements

Setting Up Steam Question

To use Steam Integration, your application must include a question asking for Steam profile URL.

Recommended Question Format:

• Question text: "Link your Steam Profile URL" or "What is your Steam profile link?"
• Question type: Short answer (text input)
• Mark as required: Yes (if Steam verification is mandatory)
• Instructions: "Ensure your profile is set to Public in Steam privacy settings"

Accepted Steam URL Formats

The bot can parse multiple Steam URL formats:

• https://steamcommunity.com/id/username (Vanity URL)
• https://steamcommunity.com/profiles/76561198012345678 (Steam ID64)
• steamcommunity.com/id/username (without https://)
• steamcommunity.com/profiles/76561198012345678 (without https://)

Privacy Settings Requirements

Applicants must configure their Steam privacy settings correctly:

Required Settings:

1. Open Steam → Profile → Edit Profile
2. Go to Privacy Settings
3. Set "My profile" to Public
4. Set "Game details" to Public
5. Set "Friends list" to Public or Friends Only (not required but helpful)
6. Save changes

Steam Data in Applications

What Staff See

When staff review applications, Steam data appears in the application thread:

Information Displayed:

• Profile Status: Public/Private indicator
• Profile URL: Clickable link to applicant's Steam profile
• Games Checked: List of games you configured
• Ownership Status: ✓ Owned or ✗ Not owned for each game
• Total Hours: All-time playtime for each owned game
• Recent Hours: Last 2 weeks playtime for each owned game
• Roles to Assign: List of Steam roles that will be assigned on Accept

Discord OAuth2 Comparison

If Discord Integration → Linked Accounts is also enabled:

• Bot checks if Steam is linked to applicant's Discord account
• Compares linked Steam ID against provided Steam URL
• If they match: Shows ✓ "Steam profiles match"
• If they don't match: Shows ⚠️ "Steam profiles don't match - verify with applicant"
• Helps detect fake profiles or incorrect URLs

Common Steam Integration Setups

Example 1: Guild Recruitment

Game: World of Warcraft
Setup:
• In Library → @WoW-Player
• 500+ hours → @Experienced
• 1500+ hours → @Veteran
• 20+ hours last 2 weeks → @Active

Result: Active veterans get @WoW-Player + @Veteran + @Active roles

Example 2: Competitive Team

Game: Counter-Strike 2
Setup:
• 1000+ hours → @CS2-Experienced
• 3000+ hours → @CS2-Expert
• 40+ hours last 2 weeks → @CS2-Active-Grinder

Recruitment Requirement: Must have @CS2-Experienced + @CS2-Active-Grinder to join competitive team

Example 3: Multi-Game Community

Games Configured: CS2, Dota 2, Apex Legends, Valorant
Setup for each:
• In Library → @{GameName}-Player
• 500+ hours → @{GameName}-Vet

Result: Players automatically tagged for all games they own and have hours in

Example 4: Activity-Based Roles

Game: Rust
Setup:
• In Library → @Rust-Owner
• 50+ hours last 2 weeks → @Rust-Hardcore
• 20-50 hours last 2 weeks → @Rust-Regular
• 5-20 hours last 2 weeks → @Rust-Casual

Result: Activity-based tiers that update with each new application (roles reflect current playstyle)

CSV Export

Download application data as CSV (Comma-Separated Values) files for use in Excel, Google Sheets, or other data analysis tools.

Download Options

All Apps

• Downloads every application ever submitted for this application type
• Includes pending, accepted, and denied applications
• Contains complete history since application was created
• File name format: AppName_All_YYYY-MM-DD.csv
• Click "All Apps" button to download

Since Last Download

• Only appears after you've downloaded at least once
• Downloads only applications submitted since your last download
• Shows date of last download (e.g., "Since last Download: 15 Dec")
• Useful for incremental updates
• File name format: AppName_Since_LastDate_YYYY-MM-DD.csv
• Timestamp updates each time you use "All Apps" or "Since Last Download"

CSV File Contents

Each CSV includes the following columns:

• User ID: Discord user ID (18-19 digits)
• Username: Discord username at submission time
• Status: Pending, Accepted, or Denied
• Submitted: Date and time of submission
• Processed: Date and time of accept/deny (if applicable)
• Processed By: Staff member who accepted/denied (if applicable)
• Thread ID: Discord thread ID for the application
• Application Counter: Sequential number (#1, #2, #3...)
• Question 1, Question 2, etc.: One column per application question with applicant's answer
• Locale: User's Discord language setting (if available)

CSV Formatting Notes

• Text fields are enclosed in quotes if they contain commas
• Line breaks in answers are preserved as \n
• Role mentions appear as role IDs (e.g., 123456789)
• Empty answers show as blank cells
• Timestamps are in ISO 8601 format (YYYY-MM-DD HH:MM:SS)
• UTF-8 encoding supports international characters

Data Retention

Control whether application answers are stored in the database after applications are processed.

Retain Answers Toggle

• Enabled: Application answers are preserved indefinitely
• Disabled: Answer content is deleted when application is accepted/denied
• Toggle can be changed at any time
• Changes only affect future applications, not existing data

What Gets Retained/Deleted

Always Retained (regardless of setting):

• User ID and username
• Application status (pending/accepted/denied)
• Submission timestamp
• Processing timestamp
• Staff member who processed
• Thread ID and link
• Application counter number

Deleted When Retention is Disabled:

• Full text of all answers
• Selected button choices
• Uploaded images (if any)
• Any PII (Personally Identifiable Information) in answers

When Deletion Occurs

• Accept: Answers deleted immediately after Accept action completes
• Deny: Answers deleted immediately after Deny action completes
• Pending: Answers retained until processed
• Scheduled actions: If schedule is active, answers retained until schedule executes

Recommended Settings

• Enable retention if: You need historical data, analytics, or record-keeping
• Disable retention if: Privacy is paramount or you handle sensitive information

Google Sheets Integration (Premium)

Automatically sync application data to a Google Sheet in real-time, eliminating the need for manual exports.

How It Works

1. Click "Sign in with Google" button
2. Google OAuth2 authorization popup appears
3. Grant AppBot permission to create and edit spreadsheets
4. Bot creates a new Google Sheet in your Google Drive
5. Sheet is automatically populated with your application structure
6. New applications sync to the sheet within 24 hours
7. Status updates (accept/deny) sync within 24 hours

Google Sheet Structure

The automatically created sheet includes:

Column Layout:

• A: User ID
• B: Username
• C: Status (Submitted/Accepted/Denied)
• D: Submission Date/Time
• E: Processing Date/Time
• F: Processed By (staff username)
• G: Thread Link (clickable)
• H: Application Number
• I+: Question 1, Question 2, etc. (one column per question)

Sheet Features:

• Header row is frozen for easy scrolling
• Columns are auto-sized for readability
• Thread links are clickable (open Discord directly)
• Conditional formatting shows status colors (green = accepted, red = denied)
• New rows append to bottom automatically

Sync Behavior

What Syncs:

• New applications (when submitted)
• Status changes (when accepted/denied)
• Staff member who processed
• Processing timestamps

Sync Frequency:

• Updates occur once per day (typically overnight)
• Not real-time - expect up to 24-hour delay
• Batch processing reduces API quota usage
• Multiple applications in same day appear in single batch

What Doesn't Sync:

• Changes made directly in the Google Sheet (one-way sync from bot to sheet)
• Applications processed before sheet was created
• Historical data (only new data after setup syncs)

Managing Your Google Sheet

Once Connected:

• "Google Sheet Connected" indicator appears
• "Open Google Sheet" link takes you directly to the sheet
• Sheet updates automatically - no further action needed
• You can edit, format, and customize the sheet freely
• Bot will continue adding new rows without affecting your changes

Removing Integration:

• Click "Remove" button to disconnect
• Sheet remains in your Google Drive (not deleted)
• Syncing stops immediately
• You can reconnect later with a new sheet
• Previous sheet won't resume syncing - new sheet is created

Data Export Best Practices

For Small Communities (Low Volume)

Recommendation: CSV exports only
• Download "All Apps" monthly for backup
• Enable data retention for historical reference
• Keep CSVs in organized folders locally
Cost: Free

For Active Communities (Medium Volume)

Recommendation: Google Sheets integration
• Premium subscription for auto-sync
• Enable data retention
• Download CSV backups quarterly
• Use Google Sheets for daily analytics
Cost: Premium subscription

For Large Organizations (High Volume)

Recommendation: Google Sheets + External Database
• Premium subscription for Google Sheets
• Enable data retention
• Export Google Sheets to external database weekly
• Use advanced analytics tools on exported data
Cost: Premium subscription + external tool costs

For Privacy-Focused Communities

Recommendation: Minimal retention
• Disable data retention
• Download CSV immediately after processing applications
• Store CSVs securely offline
• Delete online copies regularly
Cost: Free

Advanced Data Analysis

Excel/Google Sheets Formulas

Common formulas for analyzing application data:

Application Volume:

• =COUNTIF(C:C,"Submitted") - Count pending applications
• =COUNTIF(C:C,"Accepted") - Count accepted applications
• =COUNTIF(C:C,"Denied") - Count denied applications

Acceptance Rate:

• =COUNTIF(C:C,"Accepted")/(COUNTIF(C:C,"Accepted")+COUNTIF(C:C,"Denied"))*100
• Returns percentage of accepted vs total processed

Staff Performance:

• =COUNTIF(F:F,"StaffName") - Count applications processed by specific staff
• =AVERAGE(E:E-D:D) - Average time from submission to processing

Time-Based Analysis:

• =COUNTIFS(D:D,">=1/1/2024",D:D,"<2/1/2024") - Count January applications
• =SUMPRODUCT((MONTH(D:D)=1)*(C:C="Accepted")) - Accepted in January

Visualization Ideas

• Pie chart: Status distribution (Pending/Accepted/Denied)
• Line chart: Applications per day/week/month
• Bar chart: Staff processing volume comparison
• Heatmap: Application submission times (identify peak hours)

🔐 Verification System

Create a verification gate that new members must complete before accessing your server. This helps prevent spam, bots, and ensures members actively engage with your community.

How It Works

1. New member joins your Discord server
2. Bot sends verification message in designated channel
3. Member clicks "Verify" button
4. Bot automatically assigns configured roles
5. Optional: Bot logs verification in log channel

Configuration

Verification Logs

Track successful verifications by enabling the logs system:

1. Toggle Send Logs to enable logging
2. Select a log channel from the dropdown
3. Bot will post a log entry each time a member successfully verifies

Use case: Staff can monitor verification activity, identify verification issues, and track member onboarding patterns.

👋 Welcome Messages Premium

Automatically greet new members with a custom welcome message that can include text, images, and instant access to application buttons. This creates an engaging first impression and streamlines the application process.

How It Works

1. New member joins your Discord server
2. Bot automatically sends welcome message to designated channel
3. Message displays custom text, optional image, and selected app buttons
4. Member can immediately start applications or read server information

Configuration

💡 Use Cases

🔧 Troubleshooting

📅 Event Automation

Whenever someone creates a Discord Event, the bot can automatically create threads, ping roles, and post announcements. Users who click "Interested" are automatically added to the event thread.

How It Works

1. User creates a Discord Event in a monitored channel
2. Bot checks global creator requirements (if configured)
3. Bot finds matching triggers based on channel and settings
4. Bot creates a thread (public or private) in specified channel
5. Bot pings configured roles in the thread
6. Bot sends custom announcements to designated channels
7. When users click "Interested", they're automatically added to the thread
8. When users remove interest, they're removed from the thread

Global Creator Requirements

Control who can trigger event automation across all triggers. These requirements apply to all triggers before individual trigger settings are checked.

Creating Event Triggers

Triggers define when and how the bot responds to Discord Events. You can create multiple triggers for different channels or event types.

Automatic Thread Management

The bot automatically manages threads and user participation:

Use Cases

🛡️ Auto Slow Mode

Automatically apply slowmode restrictions when message frequency exceeds configured thresholds. This protects your channels from spam raids, bot attacks, and excessive messaging.

How It Works

1. Bot monitors configured channels for message activity
2. Every 5 seconds, bot counts messages in the last 5-second window
3. If message count exceeds threshold, bot applies slowmode
4. Slowmode restricts users to 1 message per configured interval
5. With auto-increment enabled, slowmode escalates for sustained spam
6. Users with "Manage Channel" or "Manage Messages" permissions are exempt

Configuration

Permission Exemptions

Users with these permissions are always exempt from slowmode:

• Manage Channel
• Manage Messages

This ensures staff can always communicate freely during spam incidents.

Use Cases

🔧 Troubleshooting

How It Works

Message Creation Process

1. Create a new message from the dashboard sidebar
2. Configure message settings (channel, color, content type)
3. Add text content and optional media (thumbnails, images, videos, GIFs)
4. Optionally add role pings and reaction role buttons
5. Send the message to the selected channel

Example Use Case: Create a "Choose Your Roles" message with buttons for Member, Gamer, Artist, and News roles. Members click buttons to self-assign roles without needing moderator assistance.

Message Types

Configuration Guide

Step 1: Create a Message

Click the NEW MSG button in the sidebar to create a message. Each message appears as "Msg 1", "Msg 2", etc. in the list.

Step 2: Select Channel

Click the Select Channel dropdown to choose where the message will be sent. The bot must have permission to send messages in the selected channel.

Step 3: Configure Message Style (Embed Only)

For embed messages, customize the appearance:

• Color: Click the colored circle to choose an embed color (default: #636ee6)
• Thumbnail: Small image in the top-right corner (optional)
• Picture/Video/GIF: Large media below the message text (optional)

Media URLs must be direct links from Discord CDN or other hosting services:
https://cdn.discordapp.com/attachments/...

Step 4: Add Role Pings (Embed Only)

Click the + button to add roles that will be mentioned when the message is sent. This notifies all members with those roles.

• Select roles from the dropdown menu
• Multiple roles can be added
• Click a role's x to remove it
• Role pings only work in embed mode

Step 5: Write Message Content

Enter your message text in the large text area. For embed messages, this becomes the embed description. For normal text, it's the message content.

Supported formatting:

• **bold text** - Bold text
• *italic text* - Italic text
• __underline__ - Underlined text
• `code` - Inline code
• ```code block``` - Code block
• [link text](url) - Hyperlinks (embed only)

Reaction Role Buttons

What Are Reaction Roles?

Reaction roles are interactive buttons attached to messages that allow members to self-assign or remove roles by clicking. This eliminates the need for manual role assignments by moderators.

Adding Buttons

1. Click the + button in the "add react role button" section
2. A new button appears with default label "Button"
3. Click the button to open the configuration modal
4. Configure the button settings (see below)
5. Add up to 25 buttons per message (Discord limitation)

Button Configuration

Button Styles

• Primary (1): Blurple/purple button (default Discord color)
• Secondary (2): Gray button
• Success (3): Green button
• Danger (4): Red button

How Reaction Roles Work

When a member clicks a reaction role button:

1. The bot checks if the member already has the role
2. If they have it: Role is removed, bot replies "❌ Removed role **RoleName**"
3. If they don't have it: Role is added, bot replies "✅ Assigned role **RoleName**"
4. The reply is ephemeral (only visible to the member who clicked)

Example Setup: Create a "Notification Preferences" message with buttons for @Updates (primary blue), @Events (green), @Announcements (blurple). Members can click to toggle which notifications they receive.

Removing Buttons

Click the x on any button to remove it from the message. This does not affect existing messages already sent - only new messages sent after the change.

Sending Messages

Send Process

1. Complete all message configuration
2. Click the arrow button (→) in the top-right corner
3. The button shows a loading spinner while sending
4. Message appears in the selected Discord channel
5. If successful, the message is sent with all configured elements

What Gets Sent

Embed Messages:

• Colored embed sidebar
• Message text as embed description
• Thumbnail in top-right corner (if configured)
• Large image/video/GIF below text (if configured)
• Role mentions above the embed (if configured)
• Interactive buttons below the embed (if configured)

Normal Text Messages:

• Plain text content only
• Interactive buttons below text (if configured)
• No role pings, thumbnails, or images

Managing Messages

Editing Messages

Changes made to messages in the dashboard only affect new messages sent after the changes. Previously sent messages in Discord channels are not automatically updated.

Deleting Messages

Click the Delete Message button to remove a message configuration from the dashboard. This does not delete messages already sent to Discord channels - those must be manually deleted in Discord by someone with Manage Messages permission.

Message Organization

• Messages appear as "Msg 1", "Msg 2", etc. in the sidebar
• Click any message to select and edit it
• Active message is highlighted with darker background
• Create unlimited messages for different purposes

Use Cases & Examples

1. Role Selection Menu

Purpose: Let members choose optional roles
Setup: Embed message with title "Choose Your Roles"
Buttons: Gamer (green), Artist (blue), Developer (purple), News (gray)
Channel: #role-selection

2. Server Rules with Agreement

Purpose: Display rules and grant Member role upon agreement
Setup: Embed with rules text and thumbnail (server icon)
Buttons: "I Agree to the Rules" (green) → assigns @Member
Channel: #rules

3. Event Notifications

Purpose: Let members opt into event pings
Setup: Embed explaining event notification types
Buttons: Tournament Alerts (red), Movie Nights (blue), Game Sessions (green)
Channel: #notifications

4. Important Announcements

Purpose: Send formatted announcements with role pings
Setup: Embed with custom color, announcement text, banner image
Role Pings: @everyone or @Members
Channel: #announcements

5. Platform Roles

Purpose: Let gamers select their gaming platforms
Setup: Embed with gaming controller thumbnail
Buttons: PC (blue), PlayStation (blue), Xbox (green), Nintendo (red), Mobile (gray)
Channel: #platform-selection

Best Practices

Message Design

• Keep text concise: Short, clear instructions work best
• Use descriptive button labels: "Get Updates Role" better than just "Updates"
• Group related buttons: Put similar roles together visually
• Match button colors to purpose: Green for positive, red for warnings, blue for neutral
• Test before sending: Verify all settings in a test channel first

Role Organization

• Create role categories: Separate notification roles from game roles from platform roles
• Use clear role names: @Game-Updates not @Updates
• Set role colors: Makes roles distinguishable in member lists
• Position roles correctly: Ensure bot role is higher than reaction roles in hierarchy

Channel Setup

• Dedicated channels: #roles or #role-selection for role menus
• Lock channels: Read-only except for bot messages prevents clutter
• Pin important messages: Pin role selection messages for easy access
• Clear old messages: Remove outdated role messages to avoid confusion

Troubleshooting

Message Won't Send

Reaction Roles Not Working

Media Not Displaying

If thumbnails or images don't appear:

• Verify URL is a direct link to image file (ends in .png, .jpg, .gif, etc.)
• Use Discord CDN links when possible: https://cdn.discordapp.com/attachments/...
• Check if external image host allows embedding (some sites block it)
• Ensure URL uses HTTPS, not HTTP
• Test URL by pasting it in browser to verify image loads

Role Pings Not Working

If roles aren't being mentioned:

• Ensure role has "Allow anyone to @mention" enabled in Discord role settings
• Or grant bot "Mention All Roles" permission
• Verify you're using embed mode (role pings don't work in normal text)
• Check that roles selected in dashboard still exist in Discord
• Save guild settings and resend the message

Button Configuration Not Saving

If button changes aren't persisting:

• Ensure you click outside the modal or close it properly after making changes
• Verify role exists in the server
• Check browser console for JavaScript errors
• Try refreshing roles from the dashboard
• Save guild settings after making button changes

Technical Details

Message Structure

Each message configuration stores:

• id - Unique identifier (timestamp-based)
• name - Display name (always "Message")
• channel - Target channel ID
• normalText - Boolean: true for plain text, false for embed
• text - Message content/embed description
• color - Hex color for embed sidebar
• thumbnail - Small image URL
• picture - Large media URL
• pings - Array of role IDs to mention
• buttons - Array of button configurations

Button Structure

Each button contains:

• btnId - Unique button identifier
• label - Button text (max 80 chars)
• style - Integer 1-4 (Primary, Secondary, Success, Danger)
• custom_id - Discord interaction ID (format: REACT + timestamp)
• emoji - Optional emoji object (id, name, animated)
• disabled - Boolean to disable button
• type - Always 2 (Discord button component type)

API Endpoint

Messages are sent via:

The endpoint retrieves the message configuration and sends it to the configured channel using the Discord API.

Interaction Handling

When a button is clicked, the bot:

1. Receives interaction with custom_id starting with "REACT"
2. Extracts role ID from button configuration
3. Checks if role exists and isn't an admin role
4. Toggles role assignment (add if missing, remove if present)
5. Sends ephemeral confirmation message to user
6. Handles errors gracefully with user-friendly messages

How It Works

Data Loading System

The statistics system uses an intelligent caching strategy to provide fast, efficient data access:

1. Initial Load: First access fetches complete dataset from server
2. Local Caching: Data stored in browser's IndexedDB (persistent storage)
3. Incremental Updates: Subsequent loads only fetch new applications added since last update
4. Freshness Check: Cached data considered fresh for 30 minutes
5. Chunked Transfer: Large datasets split into manageable chunks for stability

Performance Example: A server with 10,000 applications takes ~5-10 seconds for initial load, but subsequent visits load instantly from cache. Only new applications since last visit are fetched, typically completing in under 1 second.

When Data Updates

• Fresh Data (0-30 minutes): Loaded instantly from IndexedDB cache
• Recent Data (30 min - 7 days): Incremental update fetches only new applications
• Stale Data (7+ days): Full refresh fetches complete updated dataset
• Force Refresh: Manual refresh button clears cache and refetches all data

Global Statistics

Server-Wide Metrics

The top section displays aggregate statistics across all application types in your server:

• Total Apps: Complete count of all applications ever submitted
• Submitted: Applications completed and awaiting review
• Denied: Applications rejected by staff
• Accepted: Applications approved by staff
• Started: Applications begun but not yet submitted

Each statistic shows:

• Absolute count (e.g., "1,234")
• Percentage of total (e.g., "45%")
• Color-coded status indicators

Global Status Pie Chart

Visual representation of application status distribution across your entire server. Instantly see the proportion of submitted vs processed applications.

Timeline Stacked Bar Chart

Shows application submissions over time with each application type represented as a colored layer. Displays last 120 days of activity, allowing you to identify trends and seasonal patterns.

Use Case: Notice a sudden spike in applications? Cross-reference with server events or recruitment campaigns. See which application types are most popular during different periods.

Per-Application Analytics

Selecting an Application

Use the dropdown menu to select a specific application type for detailed analysis. The dropdown shows:

• Application name (e.g., "Moderator Application")
• Total submission count (e.g., "(1,234 apps)")
• Applications sorted by submission count (most popular first)

Application-Specific Stats Cards

Detailed breakdown for the selected application:

Interactive Hover Tooltips

Hover over any stat card to see additional details:

• Status Cards: Show 5 most recent applications with timestamps
• Staff Actions: Display staff member name and decision time
• Time Metrics: Explain what the average includes

Example Tooltip: Hovering over "Denied" shows:
Latest 5 Denied
ModeratorJohn - 1/14/26, 2:30 PM
AdminSarah - 1/14/26, 1:15 PM
StaffMike - 1/14/26, 11:00 AM

Time Analysis

Average Completion Time

Measures how long applicants take to complete an application from clicking "Start" to hitting "Submit". This metric helps identify if your application is too long or confusing.

• Calculated only for submitted applications
• Excludes outliers (applications taking more than 1 week)
• Format: Hours (27h), Minutes:Seconds (12:34m), or Seconds (34s)
• Lower times indicate smoother application flow

Benchmark: Most well-designed applications average 15-45 minutes. If yours shows 2+ hours, consider simplifying questions or reducing required fields.

Average Processing Time

Measures time between application submission and staff decision (accept/deny). Indicates how quickly your team reviews applications.

• Calculated only for accepted or denied applications
• Excludes outliers (processing taking more than 1 week)
• Shows responsiveness of your recruitment team
• Lower times improve applicant experience

Target: Aim for processing times under 24 hours for active communities. Long processing times (3+ days) can lead to applicants losing interest or joining competitors.

Visual Charts

Status Distribution Pie Chart

Shows proportion of each status (Submitted, Accepted, Denied, Started) for the selected application. Color-coded for quick status recognition:

• White/Gray (#eaeaeaff): Submitted
• Green (#26ea64ff): Accepted
• Red (#f04747): Denied
• Dark Gray (#737373ff): Left (abandoned)
• Blue (#636dd8ff): Started

Applications per Day (Line Chart)

Displays daily submission volume over the last 120 days (~4 months). The smooth line chart reveals trends, patterns, and seasonal fluctuations.

Use this chart to:

• Identify peak application periods
• Correlate activity with server events or promotions
• Predict staffing needs for review teams
• Detect declining interest (downward trend)
• Measure impact of recruitment drives

Applications per Hour (Last 4 Days)

Bar chart showing hourly submission rates over the past 96 hours (4 days). Each bar represents one hour, allowing you to identify specific times when applicants are most active.

Strategic Use: If most applications arrive 2-6 PM EST, schedule staff reviews for 3-7 PM to minimize applicant wait times. Discover your community's timezone patterns.

Timeline Stacked Bar Chart (Global)

Shows all applications across all types over the last 120 days. Each application type is a colored layer stacked on top of others, revealing which applications dominate at different times.

• Up to 5 predefined colors for visual clarity
• Additional applications get algorithmically generated distinct colors
• Hover over bars to see exact counts per application type
• Legend shows application names (not IDs)

Geographic Analytics

Top Locales

Displays the top 10 regions/countries where your applicants are from, based on Discord locale settings. Each entry shows:

• Country Flag: Visual representation using flag-icons CSS library
• Unique Users: Count of distinct users from that locale
• Percentage: Proportion of total applicants

Locale Data Includes:

• en-US 🇺🇸 - United States English
• en-GB 🇬🇧 - United Kingdom English
• es-ES 🇪🇸 - Spanish
• pt-BR 🇧🇷 - Brazilian Portuguese
• ru 🇷🇺 - Russian
• de 🇩🇪 - German
• fr 🇫🇷 - French
• And many more Discord-supported locales

Use Case: Discovering 30% of applicants are from Brazil might indicate need for Portuguese-speaking staff or translated application materials. Geographic data helps plan server events at appropriate times for your primary audience.

Staff Performance Tracking

Staff Statistics Table

Comprehensive breakdown of each staff member's application review activity. The table displays:

• Name: Staff member's Discord username
• Total: Total applications processed (accepted + denied)
• Accepted: Number of applications approved
• Denied: Number of applications rejected
• Percentage: Share of total applications processed across all staff

Table Features

• Sortable Columns: Click any column header to sort by that metric
• Descending Sort: Default sorts by total processed (highest first)
• Color Coding: Accepted (green) and Denied (red) for quick scanning
• Name Formatting: Long names truncated with ellipsis (…)
• Number Formatting: Large numbers include commas (1,234)
• Smooth Animations: Rows animate when sort order changes

Management Insights:
- Identify top performers for recognition or promotion
- Spot inactive reviewers who need follow-up
- Ensure fair workload distribution across team
- Analyze accept/deny ratios for consistency
- Track new staff member onboarding progress

Workload Distribution

The percentage column shows each staff member's share of total review workload. This helps identify:

• Overburdened staff carrying disproportionate workload
• Underutilized team members who could handle more reviews
• Need to recruit additional reviewers
• Impact when staff members go inactive

Example Analysis: If one staff member shows 65% of total processing, they're shouldering most of the work. Consider recruiting more reviewers or redistributing responsibilities.

Data Caching Technical Details

IndexedDB Storage

Statistics are stored in browser's IndexedDB, a persistent client-side database. This provides:

• Large Storage Capacity: Can store hundreds of MB of data
• Persistent Storage: Survives browser restarts and crashes
• Per-Guild Isolation: Each Discord server has separate cache
• Automatic Management: No user intervention required

Chunking for Large Datasets

When statistics exceed certain thresholds, data is transferred in chunks to prevent timeouts:

• Server determines if chunking needed based on data size
• Data split into manageable pieces (typically 1000-2000 applications per chunk)
• Progress indicator shows chunk loading (e.g., "Loading... 60%")
• Chunks merged client-side into complete dataset
• Final combined data saved to IndexedDB cache

Incremental Updates

For cached data less than 7 days old, only new applications are fetched:

1. System checks last update timestamp from cache
2. API called with ?since=TIMESTAMP parameter
3. Server returns only applications submitted after that timestamp
4. New applications merged with cached data
5. Combined dataset saved back to cache

Efficiency: A server with 5,000 total applications but only 50 new ones since yesterday will transfer just 50 applications (~10 KB) instead of all 5,000 (~500 KB). This is 50x faster and uses 98% less bandwidth.

Cache Information Display

The header shows cache details for transparency:

• Source: "IndexedDB Cache", "Fresh API", "Incremental update (+50 new)"
• Last Updated: Timestamp of when data was last refreshed
• Size: Total storage size in MB (e.g., "2.35 MB")
• Total Apps: Count of applications in cache

Best Practices

Performance Optimization

• Let Cache Work: Don't force refresh unless absolutely necessary
• Wait for Load: Large datasets may take 10-30 seconds on first load
• Use Incremental: System automatically chooses best update strategy
• Monitor Size: Cache over 50 MB may indicate need for data archival

Data Analysis Tips

• Compare Periods: Look at different date ranges to identify trends
• Cross-Reference: Match spikes with server events or campaigns
• Monitor Ratios: Track accept:deny ratio for quality control
• Time Awareness: Consider timezones when analyzing hourly patterns

Using Insights for Improvement

Scenario 1 - High Denial Rate: If 70%+ applications are denied, your requirements may be unclear. Add FAQ section or example good applications.

Scenario 2 - Long Completion Times: Average over 1 hour suggests application too complex. Consider removing redundant questions or simplifying language.

Scenario 3 - Slow Processing: 48+ hour processing means applicants waiting too long. Recruit more reviewers or schedule dedicated review sessions.

Scenario 4 - High Started/Low Submitted: Many started but few submitted indicates applicants abandoning process. Simplify or add progress indicators.

Troubleshooting

Statistics Won't Load

Data Seems Inaccurate

If numbers don't match expectations:

• Cache Staleness: Force refresh to get latest data
• Incomplete Sync: If loading interrupted, force refresh to restart
• Status Mismatch: Ensure applications properly marked with status
• Time Calculations: Check that submitTime and timeStarted fields exist
• Staff Tracking: Staff actions only count if using Accept/Deny buttons

Charts Not Displaying

If charts appear blank or broken:

• Ensure Chart.js library loaded (check browser console)
• Verify data exists for selected application type
• Try selecting different application from dropdown
• Check if applications have required timestamp fields
• Clear cache and reload if charts consistently fail

Slow Performance

If statistics page is sluggish:

• Clear Old Cache: Force refresh clears and rebuilds cache
• Browser Resources: Close unnecessary tabs consuming memory
• Large Datasets: 50,000+ applications may impact performance
• Chart Rendering: Complex charts with many data points are resource-intensive
• Consider Archival: Archive old applications to reduce dataset size

Missing Staff Names

If staff statistics show IDs instead of names:

• Staff names captured at time of decision, not current display names
• If staff member left server, historic name preserved
• Ensure bot can see staff member's profile when they make decisions
• Username changes don't retroactively update historical statistics

Command Locations

Commands are available in different contexts depending on their purpose:

• Server Commands: /info and context menu commands work within Discord servers
• DM Commands: /cancel only works in direct messages with the bot
• Context Menus: Right-click user profiles to access application history

💡 Quick Tip

Use /info as your central hub for server statistics and quick actions. Administrators see additional options for managing applications and server settings.

Server Statistics Display

Based on your server's premium status, you'll see different statistics:

Free Tier Servers

Example:
This Month Apps: 12/15
This Month Votes: 8/40

Shows monthly application usage out of the free tier limit and vote count toward unlocking additional features.

Vote Servers

Example:
This Month Apps: 28/40
This Month Votes: 42/40

Servers that reach 40 votes unlock increased limits (40 apps per month).

Prepaid Servers

Example:
Apps Utilized: 156/500

Shows total application usage out of purchased application cap (no monthly reset).

Premium Servers

Premium subscribers see no usage statistics as they have unlimited applications.

Quick Action Buttons

The command provides immediate access to common tasks:

⏳ Show Incomplete Apps

View all applications that users have started but not yet submitted. Useful for following up with applicants who may need assistance.

📋 Show Submitted Apps

View all submitted applications awaiting review. This gives you a quick overview of pending applications without opening the dashboard.

🎁 Gift Premium - Apps

This button appears for non-premium servers and allows you to purchase premium features or application packs. It shows when:

• Server doesn't have free premium
• Server doesn't have an active premium subscription, OR
• Premium subscription last payment was over 32 days ago

Application Enable/Disable Controls

Users with appropriate permissions see additional controls for managing applications:

Who Sees These Controls?

• Administrators: See controls for ALL applications (up to 25 due to Discord limits)
• Global Disableable Permission: Users with roles assigned in "Allow Disableable Apps" setting see controls for all applications
• Per-App Permission: Users with roles assigned to specific applications see controls only for those applications

Display Format

Controls appear as either buttons or a dropdown menu:

• Buttons: When you have permission for 5 or fewer applications, each appears as a labeled button
• Dropdown Menu: When you have permission for more than 5 applications, a multi-select menu appears instead

Example Button: [Moderator Application]
Example Dropdown: Select apps to disable/enable... (with checkboxes for each app)

Important Links

The info embed always includes these helpful links:

• Video Tutorial: Complete setup walkthrough
• Setup Guide: Step-by-step configuration instructions
• Dashboard: Access the web-based configuration panel
• Premium: Learn about premium features and pricing
• Invite Bot: Add AppBot to another server
• Support Server: Get help from the community
• Vote for Bot: Support AppBot on Top.gg (includes guild-specific vote link)

💡 Use Cases

• Quickly check how many applications your server has processed this month
• Enable/disable applications during off-peak hours without accessing the dashboard
• Share vote links with your community to unlock free premium features
• Monitor incomplete applications to follow up with users who need help

How to Use

1. Right-click on any user's profile in your server
2. Navigate to Apps in the context menu
3. Select View User Applications
4. The bot displays the user's complete application history

Information Displayed

The command shows a comprehensive overview of the user's history with your server:

User Information

• Username: Current Discord username
• User ID: Discord snowflake ID
• Discord Created: When the Discord account was created
• Joined: When the user joined your server (or "user left" if no longer a member)

Application History

All applications are listed with status indicators and clickable links:

Status Indicators:
⚪ Submitted (awaiting review)
🟢 Accepted
🔴 Denied/Rejected

Each application shows:

• Status indicator
• Submission date (e.g., "Jan 14 2026")
• Clickable link to the application thread

Example Display:
[🟢 Dec 15 2025 app] (link)
[⚪ Jan 8 2026 app] (link)
[🔴 Jan 10 2026 app] (link)

Incomplete Applications

If the user has started but not completed any applications, these appear at the top in a separate gray embed:

What It Shows

• Timestamp: When they started the application (relative time, e.g., "2 hours ago")
• Answers Preview: Their current progress through the application questions
• Question Numbers: Shows which questions they've answered so far

Example Incomplete App:
User did start an application 3 hours ago, but did not complete it yet

1 I'm interested in joining the moderator team
2 Yes, I have previous experience
3 About 15 hours per week...

Each answer is numbered and truncated if too long. This helps you see if users are struggling with specific questions or abandoning applications midway.

Display Limits

To prevent embed overflow, the command has built-in limits:

• Character Limit: Application list is truncated at ~3400 characters
• Answer Preview: Each answer in incomplete applications is limited to prevent spam
• Maximum Dynamic Limit: Answer length is calculated as (1800 / number of answers) to fit all questions

If a user has an extensive application history, older applications may be truncated with the most recent always shown.

Applications Sorting

Applications are displayed in a specific order for easy review:

• Incomplete applications: Always shown first in a separate embed
• Completed applications: Listed in reverse chronological order (newest first)
• Only applications with threads: Applications without thread IDs are filtered out

💡 Use Cases

• Background Checks: Review a user's application history before granting elevated roles
• Pattern Detection: Identify users who repeatedly apply and get denied
• Follow-ups: See if users abandoned applications and reach out to assist them
• Account Age Verification: Check Discord account creation date to identify potential alt accounts
• Re-applications: Verify how long ago a user was previously denied before allowing them to reapply
• Training: Review accepted applications to train new moderators on what good applications look like

Troubleshooting

"Command available with premium subscription"

Your server needs premium status to use this feature. Click the "Gift Premium" button to upgrade or check your subscription status in the dashboard.

"No apps found for this user"

This user has never started an application in your server. They may be a new member or have never attempted to apply.

"No server found"

The bot hasn't been properly configured for this server. Run setup through the dashboard first.

"Command can only be used inside a server"

Context menu commands don't work in DMs. Use this command within your Discord server.

How It Works

When a user types /cancel in their DMs with AppBot:

1. If an in-progress application exists, the bot presents a confirmation message
2. The user chooses to either delete the application or continue with it
3. Deletion is immediate when confirmed - no additional confirmation required

The Confirmation Message

Users see a clear embed with two options:

📝 CANCEL APP IN PROGRESS?

Do you want to delete the current app and start a new one?

🔴 DELETE APP - Delete your current app
🟢 CONTINUE APP - Continue your current app

Delete App Button (Red)

Clicking this button immediately and permanently deletes the in-progress application. The user can then start a new application from scratch.

Continue Current App Button (Green)

Clicking this button dismisses the confirmation and allows the user to continue where they left off in their application.

When to Use /cancel

Users typically use this command when:

• They made significant mistakes in their answers
• They want to change their application strategy
• They accidentally started the wrong application type
• They want to rewrite their responses with a different tone
• They need to step away and want to start fresh later

Important Behavior

• One Application at a Time: Users can only have one in-progress application at a time, so /cancel always affects their current active application
• Immediate Deletion: There is no "undo" option once the delete button is clicked
• No Response If No Apps: If the user has no in-progress applications, the command does nothing (silent failure)
• DM Requirement: The command will not work in server channels

💡 User Education

Consider informing your applicants about this command:

• Include it in your application start message
• Mention it in your server rules or application guidelines
• Use it as a safety net for users who panic during applications

Example Guidance:
"If you make a mistake or want to start over, simply DM the bot with /cancel to delete your current application and begin fresh."

Troubleshooting

"Nothing happens when I type /cancel"

This means you don't have any in-progress applications. The command only works if you've started but not yet submitted an application.

"The bot cannot start the Direct Message process"

You need to enable Direct Messages in your Discord privacy settings:

1. Go to User Settings → Privacy & Safety
2. Enable "Allow direct messages from server members"
3. Try the command again

See Discord's official guide: https://support.discord.com/hc/en-us/articles/217916488

"I want to cancel a submitted application"

Once an application is submitted, it enters the review queue and cannot be canceled via /cancel. Contact a server moderator to withdraw your application manually.

User Variables

These variables reference the applicant's Discord account information:

💡 Username Fallback Logic

AppBot intelligently handles empty name fields to prevent blank spaces:

• If {username} is NOT used in your template, empty fields automatically fall back to username
• If both {nickname} and {globalname} are empty, only the first one gets the username fallback
• This prevents duplicate usernames when using multiple name variables

Staff/Acceptor Variables

These variables reference the staff member who accepted or denied an application:

Application Variables

These variables provide information about the application itself:

Server Variables

These variables provide information about your Discord server:

Role Mentions

You can mention Discord roles using their ID:

Special Mentions

Question & Answer Variables

These variables pull data from the application questions and user responses:

💡 Nested Variables in Questions

Questions can contain other variables that get resolved recursively. For example, if Question 1 is "What is your name, {username}?", the {question1} variable will output the fully resolved text with the username filled in.

Advanced: Rule Variables

Rule variables are used for conditional logic in thread names and nickname changes:

How Rules Work

Rules allow you to create dynamic content based on user choices:

• For text questions: You set a "match text" (regex or string) and "replace text"
• For button questions: Each button can have custom text that appears when selected
• Multiple rules can be combined in a single template

Character Limits

Some fields have Discord-imposed character limits that affect variable output:

• Thread Names: Maximum 100 characters (truncated automatically)
• Nicknames: Maximum 32 characters (truncated automatically)
• Embed Descriptions: Maximum 4096 characters
• Message Content: Maximum 2000 characters

AppBot automatically truncates thread names and nicknames to fit Discord's limits. Plan your variable combinations accordingly.

Using Variables in Different Contexts

Thread Names

Available variables: All variables, including rule variables

Example: "App #{app_count} - {username} - {rule1}"

Nickname Changes

Available variables: All variables, including rule variables

Example: "[{rule1}] {answer2}"

Messages & Embeds

Available variables: All variables EXCEPT rule variables

Example: "Hey {user}, your application '{appname}' has been {app_status}!"

Google Sheets

All variables work in Google Sheets column mappings, allowing you to export any application data.

💡 Best Practices

• Test your variables: Create a test application to verify variable output before going live
• Use {user} for pings: Use {user} in messages when you want to notify someone, {username} for display-only
• Combine wisely: Consider character limits when combining multiple variables in thread names
• Fallback awareness: Remember that nickname and globalname fall back to username if empty
• Rule placement: Place rule variables at the end of thread names so truncation doesn't cut off important info

Troubleshooting Variables

Variable Not Replacing

If a variable shows as literal text (e.g., "{username}" instead of "JohnDoe"):

• Check for typos in the variable name
• Ensure you're using curly braces, not other brackets
• Verify you're using the variable in a supported context

Empty Variable Output

Some variables may be empty in certain contexts:

• {acceptor} variables are empty in Submit actions (no staff involvement yet)
• {thread_id} is empty for started applications (no thread created yet)
• Answer variables are empty if the user skipped optional questions

Rule Variables Not Working

Rule variables only work in thread names and nickname changes. They will appear as literal text in messages or embeds.

Truncated Content

If your thread name or nickname appears cut off, you've exceeded Discord's character limit. Simplify your variable template or use shorter answer options.

Complete Example: Application Workflow

Here's how variables work together in a complete application flow:

Submit Action:

• Thread Name: "App #{app_count} - {username}"
• DM to User: "Thanks {user}! Your application has been submitted. View it here: {app_link}"
• Staff Channel: "{<@&123456> New {appname} from {username} (ID: {user_id})"

Accept Action:

• Rename Thread: "[ACCEPTED] {username} - {rule1}"
• Change Nickname: "[{rule2}] {username}"
• DM to User: "Congratulations {user}! Your {appname} was accepted by {acceptor}."