Skip to content
Moderator Guide

Moderator Guide

Moderators keep GearCheck running smoothly: evidence misses, wrong threads, support tickets, manual reviews, and everything between.

On This Page13 sections

Tips for Mods

  • Check /mod info before overriding. It shows you what the bot actually saw in the evidence, which helps you decide whether the override is warranted.
  • If you keep overriding the same item, the real fix is probably adding an alias. Tell your build editor to check /pack test and update the item.
  • Run /mod active periodically during gear checks to catch threads that are stuck or abandoned.
  • Set up the audit channel early. You will be glad you did the first time someone disputes a score.

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:

Example for /mod set-mod-role

/mod set-mod-role role:@Officers

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

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.

Thread cleanup (deleting config for archived threads) is not part of that default set: admins can grant it separately in Settings on the dashboard.

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:

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.

One permission model, two surfaces

Every GearCheck permission is checked identically on the bot and on the web API. Mapping a role or tweaking a permission in the dashboard takes effect for the matching slash commands too, with no separate Discord-side setup.

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 included on the Free plan; Pro lifts the limit on activity and difficulty role mappings. 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.

Example for /admin set-verified-role

/admin set-verified-role role:@Verified min_score:85

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.

Example for /admin set-activity-role

/admin set-activity-role activity:raids role:@Raid-Ready min_score:90

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.

Example for /admin set-difficulty-role

/admin set-difficulty-role difficulty:m10 role:@M10-Cleared min_score:90

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

Example for /admin activity-roles

/admin activity-roles

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).

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.

Example for /mod override

/mod override build:tank-build score:85

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.

Example for /mod transfer

/mod transfer new_owner:@SomePlayer

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:

Example for /mod refresh

/mod 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.

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.

Example for /mod info

/mod info

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.

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.

Example for /mod active

/mod active

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.

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.

Example for /mod cleanup

/mod cleanup

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.

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

Example for /mod tickets

/mod 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

Example for /mod resolve-ticket

/mod resolve-ticket ticket_id:42

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.

Audit Channel

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.

In the Dashboard

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.

Step by step: Using the Gear Checks Page.

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.

Step by step: Setting Up and Using Notifications.

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.

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 Ticket reopened entry in the audit ledger.

Step by step: Setting Up and Using Tickets.

Audit Log

The Audit Log sits under Operations in your server's dashboard.

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.