Unknown accounts never land in your real channels.
Setup creates the roles and writes the channel permissions for you. New arrivals get a holding area with the sign-up channel and nothing else, PUGs get access scoped to the raid they came for, and it is the same bot doing verification, roles, signups and recruitment. One thing to install, one thing to keep upright.
- #welcomeNew arrivals, read only
- #pug-signupUnverified, Applicant
- #generalMember, Raider, Guest
- #raid-signupsRaider
- Raid VoiceRaider
- #officer-chatOfficer, Admin
This is what the wizard writes. @everyone loses View Channel on the channels that matter, the roles you named get it back, and Hootus grants himself only enough to post in the ones he just shut.
Everyone arrives somewhere. It is not your general chat.
The Discord default is that a fresh account can see your server. The wizard changes that in one pass: @everyone loses View Channel on the channels you care about, and the roles you named get it back. An unknown arrival gets as far as welcome and the sign-up channel, which is exactly as far as they need to go.
Be clear about what this is not. Hootus does not read your messages for spam and is not an anti-raid moderation bot. What he gives you is structure: a gated door, scoped roles that expire, and somewhere to put people who have not proved anything yet.
They arrive through a link you handed out
A link a raid leader pulled out of /raid pug-invite, the public apply page, or your own member invite. Hootus caches the invite list and works out which one was used, so an arrival is attributed rather than anonymous.
They land in a holding area
Sign-up arrivals get the Applicant role and see the sign-up channel. PUG arrivals get the PUG role. Neither one opens general, raid chat, or anything in the officer category, because @everyone lost View Channel on all of it during setup.
Approval opens exactly one raid
An approved PUG is added to that raid thread and its voice channel, and nothing else. When the raid closes, the scheduler takes that access back without anyone remembering to.
Going quiet drops them to the hold
Seven days with no active raid or group and the PUG role comes off. They keep the sign-up channel, so they can join the next raid without an officer approving them twice. Nobody is kicked.
- Administrator asked for at install
- 0Administrator asked for at install
- Idle before a PUG drops to the hold
- 7dIdle before a PUG drops to the hold
- Between permission self-checks
- 30mBetween permission self-checks
- Bot doing all of it
- 1Bot doing all of it
A PUG is a guest of one raid, not a resident of your server.
Paste a raid link in trade chat and whoever clicks it arrives on the PUG role. That opens the raid thread and the raid voice. It does not open general or raid chat, and it was never anywhere near the officer category. When the raid closes the access closes with it, and when they go quiet the role lifts itself.
- Day 0Joins on the raid linkPUG role, the raid thread, and the raid voice channel. Nothing else in the server opens.
- Raid closesScoped access comes back offThread and voice permissions are revoked by the scheduler, not by an officer remembering, and the raid invite is revoked with them. A paste from three weeks ago in some realm chat is a dead link.
- Day 7Quiet, so the role liftsNo active raid or group for a week. The PUG role comes off, the sign-up hold goes on, and Hootus DMs them to say so.
- WheneverThey come back on their ownThe sign-up channel is still there, so they join the next raid without a second approval.
Hootus DMs them when the role lifts and posts the summary to your officer channel. His words, not ours: still a perch here for you.
- Never kickedAn idle PUG stays in the server. They keep the sign-up channel and can join the next raid without asking anyone, which is how a decent number of them end up recruited.
- Scoped, not permanentThread and voice access is granted per raid and revoked when that raid closes, so the pickup healer from last month is not still reading your raid chat in the middle of a tier.
- Blocked means blockedBlock a PUG and they lose the role, the threads and the voice. A later invite link does not quietly walk them back in through the front door.
Name the jobs. It is the same bot doing all of them.
Not a boast about scope. This is the stack you would otherwise be running side by side, each with its own permissions, its own outage, and its own row in your member list.
The usual arrangement is a scheduler for raid night, a moderation bot doing reaction roles so people can pick their own class, and something else again holding the roster. That middle one is the interesting failure. A reaction role is a claim: whoever clicks the Mage emoji is a Mage, and it stays true until they reroll and forget. Hootus reads the class off the character you verified on the armory and keeps the role in step with it. Same coloured name in your member list, except this one had to be earned.
Discord roles decide it. Administrator does not.
Every feature is a key, and you tick which Discord roles hold it. Your Raid Lead role opens the raid tools, your Officer role opens recruitment, and a role you did not tick gets a quiet ephemeral no. There is no rank ladder to maintain and no second permission model living beside Discord.
Four things sit above the map so nobody locks themselves out of their own server: the guild owner, anyone holding Discord Administrator, the admin roles you configured, and the instance super admins. Three settings pages are never configurable, the ones that hand out access in the first place.
- Access is a Discord role ID against a feature key, and nothing else
- No rank ladder, no tiers, no second permission system to keep in step
- Guild owner, Discord Administrator, your admin roles and super admins always pass
- Permissions, Access and Verification settings stay admin-only, always
- A feature that ships after your last save falls back to a sensible audience instead of locking everyone out
- The bot reads roles live from the gateway, the web reads the synced copy, so a role change lands there first
He tells you the day the hierarchy goes wrong.
Discord will not let a bot hand out a role that sits above its own. That is the single most common way a working setup quietly stops working, usually because somebody dragged a role for an entirely unrelated reason on a Tuesday.
Hootus checks his own permissions and his position in the role list on boot, then every thirty minutes. When something is missing he posts once to your officer channel, naming the permission and what he wanted it for. He does the same when two of the roles he manages end up with the same name, which is the other way this goes sideways.
HootusPlootus is missing some permissions.
- Manage Roles Assign Raider, Guest, PUG and class roles, and set channel permissions.
- Role position the HootusPlootus role sits at or below Raider. Drag it above in Server Settings, Roles, otherwise the bot cannot assign roles to those members.
Fix it and this same message is edited into a confirmation naming what was granted, rather than sitting in the channel looking broken forever.
One notice, edited in place. He does not repost the same complaint every half hour, and he does not go quiet about it either.
Set the roles once. Let the door stay shut.
Add HootusPlootus and walk the wizard. It creates the role set, writes the channel permissions, and puts every unknown arrival in a holding area with a sign-up channel and nothing else. No Administrator, no config files.