Moderator Guide

Who Counts as a Mod?

By default, anyone with one of these permissions can use mod commands:

• Administrator permission
• Manage Messages permission

You can also configure a specific mod role using /mod set-mod-role role:@Officers. Anyone with that role will have access to all mod commands, even without Manage Messages.

GearCheck uses a three-tier staff model. Permissions are resolved per server and enforced the same way for both Discord slash commands and the web dashboard, so a person sees exactly the same surface in either place.

Admins

Anyone with the Discord Manage Server (or Administrator) permission is treated as an admin and always passes every GearCheck permission check. There is nothing to configure for admins, and their access cannot be narrowed by the per-permission settings below.

Moderators

Moderators are mapped by role or by individual user. They handle day-to-day gear checks and ticket work. Map a mod role with:

On servers that have never customized their permissions, moderators get the curated day-to-day set, which includes:

• tickets_view see open support tickets
• tickets_resolve resolve support tickets
• overrides apply score overrides
• transfers transfer thread ownership
• reviews_resolve act on the review queue
• cleanup run thread cleanup

The default mod set also covers viewing analytics, sessions, scheduling, notifications, and builds, plus running build tests. It deliberately leaves out configuration surfaces such as editing or creating builds, channel setup, role config, role gates, and plugin management, which stay admin-only until you grant them.

Assistants

Assistants are also mapped by role or user, but get view-only access by default: they can see tickets, reviews, sessions, scheduling, analytics, and builds, but cannot resolve, override, transfer, or change anything. Manage assistant mappings with:

• /admin set-assistant-role role:@Trainees map a role as assistants (view-only by default)
• /admin clear-assistant-role remove the assistant role, users, and saved permissions

Customizing Permissions

Defaults only apply until you save your own permission set. Open the web dashboard under Settings > Staff Roles to grant or revoke individual permissions per tier, or to grant everything at once. Once you save, your stored set is what gets enforced everywhere, replacing the defaults above.

To review who is mapped and which permissions are in effect, run /admin staff in Discord, which shows the admin, moderator, and assistant configuration in one place.

Score Overrides

This is probably the mod tool you will use the most. When someone has the right build but automated evidence parsing gave them a bad score, you can set a verified minimum.

The override sets a verified minimum, not an exact score. If the member later submits better evidence and gets 90%, the score stays at 90%. The verified minimum only kicks in when the automated score is lower than the override.

When to use overrides

• You can clearly see the gear is correct in the submitted evidence, but the parser missed things due to image quality, formatting, or a known catalog gap.
• The build spec is missing aliases, and you do not want to make the member wait while you fix them. Override now, fix aliases later.
• A game update changed item names, and the build spec has not been updated yet.

Thread Transfers

Sometimes the wrong person starts a gearcheck thread, or someone needs to verify on a different character. The transfer command lets you change who owns the thread.

This updates the thread ownership and resets the workflow. The new owner starts fresh with the build selection. Run this command inside the thread you want to transfer.

Dashboard Refresh

If the dashboard in a thread gets out of sync, for example if buttons stop responding after a bot restart, you can force a refresh:

This regenerates the entire dashboard message with fresh buttons and the latest state. All existing scores and progress are preserved. The old dashboard message gets replaced with a new one.

Monitoring Active Workflows

Want to see who is currently going through a gearcheck? The active command gives you an overview of all in-progress workflows.

This shows you thread names, owners, selected builds, and current status. Useful for keeping an eye on things during gear checks, or for finding threads that got abandoned.

Thread Info

For a deep look at a specific thread, run /mod info inside that thread. You will see the thread owner, which builds they have selected, their scores, any overrides that have been applied, and the current workflow state.

This is the first thing to check when someone reports a problem with their gearcheck. It tells you everything the bot knows about that thread.

Dashboard Review Queue

The dashboard review queue is the staff-friendly view of sessions that need human attention. It includes failed or partial checks, structured evidence summaries, links back to the Discord thread, and filters for build, activity, member, verdict, and manual-review state.

Use it when a Discord thread is too noisy or when you need to process a batch of reviews. The Discord commands still work, but the dashboard is better for sorting, filtering, comparing, and exporting.

Web Inbox

Notification rules can send messages to Discord channels, DMs, and the Web Inbox. The inbox gives staff a dashboard-native place to review alerts without hunting through Discord. It is especially useful for review queue alerts, RaidHelper readiness gaps, support ticket activity, billing attention, and operational notices.

Inbox entries are driven by the same notification rules as Discord delivery, so if an expected item is missing, check the notification rule, destination, cooldown, quiet hours, and dedupe settings.

Where to find it

• Inbox dashboard : read alerts routed to the Web Inbox; also reachable from the sidebar bell. Pick your server from the dashboard, then open Inbox.
• Notifications dashboard : build and edit the rules that decide what gets sent and where, including the Web Inbox destination, cooldown, dedupe, and quiet hours.
• Setting Up and Using Notifications : step-by-step tutorial for the rule builder, destinations, test, and delivery history.
• Bot Status Use Cases : destination health, scanners, and operational alerts.
• Bot Messages : override the bot's Discord copy with Bot Messages.

Support Tickets

Members can submit support tickets with /support. Tickets go to the configured support user, set by the admin with /admin set-support-user, and are also visible to mods.

Before any of this works, an admin must pick who receives tickets by running /admin set-support-user (Manage Server permission). You can optionally also run /admin set-ticket-channel to mirror every ticket into a dedicated channel. Until a support user is set, submitters are told their ticket was saved but no one was notified, so do this first.

How members submit a ticket

The flow only works inside a gearcheck thread. A member runs /support there (or clicks the Support button on the gearcheck message); running it anywhere else returns an ephemeral warning to use it inside a thread. From there the bot walks them through three steps:

• Category. Build Help, Bot Help, Suggestions, or Other.
• Issue type. A short list of specific options tailored to the chosen category (for example, Build Help offers "Requirement not detected", "Wrong requirement detected", and "Wrong score").
• Description. A modal where they describe the issue in 10 to 1,000 characters.

Every step is ephemeral, so the member's selections and description stay private to them. The submitting thread is captured automatically so reviewers can jump straight back to it.

Where tickets go

Once submitted, a ticket is saved to the server config and delivered two ways:

• DM to the support user. The configured support user receives the ticket as an embed with the submitter, category, issue type, description, and a jump link to the thread.
• Post to the ticket channel. If a ticket channel is configured, the same embed is posted there with a persistent green Resolve button that any mod can click to close the ticket in place.

The Support button shares the exact same flow as /support, so members can open a ticket without remembering the command. The button persists across bot restarts, so it keeps working on older gearcheck messages.

Viewing Open Tickets

This shows all open tickets for the server, along with who submitted them and when. Review each ticket, take action such as overriding or fixing a build, and then resolve it.

Resolving a Ticket

Marks the ticket as resolved. The member who submitted it will not get a notification, so you may want to follow up in the thread or DM them if the situation warrants it.

Tickets on the web dashboard

Every ticket also appears on the dashboard's Tickets page, so you can triage support requests without leaving the browser. It shows the same queue as /mod tickets, plus richer detail and reopen support.

• Open / Resolved / All tabs filter the queue by status. Open is the default working view; switch to Resolved to revisit closed tickets or All to see the full history.
• Expandable rows click a ticket to reveal the full description, the submitter, the created date, an Open in Discord deep link to the ticket thread, and the resolution details once it has been closed.
• Status history timeline each expanded ticket lists its recent status changes, who acted and from where (web or Discord), and a reopen count if it has been reopened.
• Inline Resolve and Reopen resolve an open ticket directly from the row (a modal lets you attach an optional resolution message), or reopen a resolved one with a single click.

Resolving a ticket from either the web dashboard or Discord posts a notification to the submitter in their ticket thread, including your resolution message when you add one. Reopening records a support.ticket_reopened event in the audit ledger.

By default the Tickets page needs the tickets_view permission to view, and tickets_resolve to resolve or reopen. Mods get both by default; assistants get view-only access.

Cleanup

Over time, threads get archived or deleted, but the bot's config entries for those threads stick around. The cleanup command prunes stale data.

This removes config entries for threads that no longer exist. It is safe to run at any time and will not affect active threads. Good practice to run periodically in busy servers.

Audit Log

If an admin has configured an audit channel with /admin set-audit-channel, the bot logs key events there automatically:

• Score calculations and status changes
• Mod overrides and who applied them
• Role assignments and removals
• Thread transfers
• Build changes, including creates, deletes, and edits
• Failsafe lockouts

The audit log is your paper trail. If there is ever a question about what happened or who did what, it is all there. We recommend setting this up early, especially in larger servers.

The dashboard also includes an event ledger and stored data view for staff who need searchable history, filtered exports, and a fuller view of what the guild has produced over time.

Verified Roles & Priority

When a player passes a gearcheck, the bot can automatically assign a Discord role. You can configure roles at three levels: a global fallback, per-activity roles, and per-difficulty roles. Each role carries its own minimum score, so a player only receives it when their result clears that threshold.

Automatic role assignment is a Pro feature. Set min_score on any of these commands to control how high a player must score before the role is granted (default 85).

Global verified role

The global role is the catch-all reward. It is assigned on any passing gearcheck that doesn't match a more specific activity or difficulty role.

Per-activity roles

Activity roles target a specific encounter or content type (for example wurmmy or gorgon). When a check is run for that activity and the score meets the role's minimum, the matching role is assigned.

Per-difficulty roles

Difficulty roles target a difficulty tier such as m10 or hard. They let you reward players who clear a higher bar without creating a separate activity for every tier.

Which role gets assigned

On a passing check the bot evaluates roles in this order:

• Activity the role for the activity the check was run against, if one is configured and the score clears its minimum.
• Difficulty the role for the difficulty the check was run against, if one is configured and the score clears its minimum.
• Global the fallback role, assigned only when no activity or difficulty role was granted.

Activity and difficulty roles can both be granted on the same check if both match and clear their minimums; the global fallback is skipped whenever any activity or difficulty role is assigned. A role is never re-added if the player already has it.

Review your role setup

This shows the full picture: the global fallback, every per-activity role, and every per-difficulty role, each with its minimum score and whether it is enabled. The footer reflects the same priority order the bot uses at gear check time.

To remove a role mapping, use /admin clear-activity-role for an activity or /admin clear-difficulty-role for a difficulty. Clearing an activity or difficulty role falls back to the global verified role (if one is set).