Autorole and verification
Roles handed out automatically, roles restored on rejoin, and a self-serve verify button: three systems that all act on a member the moment they join, and the order they run in.
Three separate systems can hand a member a role without a moderator touching anything: autorole gives out roles on join, role history restores the roles someone had before they left, and verification lets a member give themselves a role by clicking a button. If you've watched a returning member get roles back that nobody re-assigned, this page is why.
What happens, in order, when someone joins
Before any of the three below runs, Righteous decides containment first: a mute, jail or timeout the member left with is re-applied, if it's still owed. Leaving is not a pardon, and this step runs ahead of everything else on purpose, so a punished member can't outrun their punishment by getting their old roles handed straight back.
If containment fires, that's the end of the pipeline for that member. Role history and autorole are both skipped, not just deferred to after: a fresh Verified role or a restored role set would undo the point of the punishment the moment it landed, so neither runs at all while a mute or jail is being re-applied. Only a member who rejoins clean gets the rest of the pipeline: role history, then autorole, then the welcome/join-DM tail described on the server messages page.
A punishment row that expires while the member is away is resolved and never re-applied: the record is a live clock, not a stamp that lasts forever.
Give roles automatically when someone joins: autorole
,autorole needs Manage Roles. Every role on
the list is added to every new member, as long as the role sits below the bot's own highest role:
one above it and Discord itself refuses the assignment.
Syntax
,autorole add <role>
Example
,autorole add @Member
Syntax
,autorole remove <role>
Syntax
,autorole list
Syntax
,autorole clear
clear empties the whole list in one command: there's no per-role undo, so check ,autorole list
first if you're not sure what's on it.
Restore roles when someone rejoins: role history
Autorole only fires once, on the first join. Role history is the separate setting that gives a returning member back the roles they held when they left, as long as they rejoin inside a time window. It's off by default. The window used to be a fixed ten minutes on the free tier, which was often too short for someone to notice they'd left and rejoin in time, so it's now configurable everywhere instead.
Syntax
,autorole history [on|off]
Example
,autorole history on
Turning it on and off, checking its status, and setting the window are all free on every tier. Server Premium doesn't unlock the setting, it raises the ceiling the setting is allowed to reach:
Syntax
,autorole history duration <value>
Example
,autorole history duration 2h
Configuring this is free. Server Premium only raises the ceiling
A duration like 2h, 45m or 1d is required: a bare number is refused. The ceiling is 12
hours on the free tier and 48 hours with Server Premium. Asking for longer than your own
ceiling is refused outright rather than silently capped, and the refusal names the ceiling you
actually have, so a request that looks wrong never quietly becomes a different one. Turn the
setting on without picking a duration and you get 12 hours by default.
A server that lapses out of Server Premium keeps whatever duration it had configured. A 48-hour
window set while paying is not rewritten or reset: it's simply served at 12 hours, the free
ceiling, until the subscription comes back, at which point the stored 48 hours takes effect again on
its own. ,autorole history run bare, and the config panel, both report the window actually in
effect rather than the stored one, so a lapsed server correctly sees 12 hours rather than the 48 it
has saved.
Role history only restores roles that still exist and still sit below the bot's own role at the moment the member rejoins: a role deleted, or moved above the bot, while they were away is dropped silently rather than causing an error.
Let members verify themselves: verification
,verification posts a button in a
dedicated channel; clicking it hands the clicker one role. It needs Manage Server, and it is
prefix-only: there is no /verification slash command.
Set it up
Syntax
,verification setup
This creates a #verify channel, a fresh Verified role with no permissions attached, and a
message with a Verify button. It touches nothing that already exists in your server. Setup
does not hide anything on its own: an unverified member can still see every other channel until
you deny View Channel for @everyone and allow it for the new role, wherever you want
verification to actually gate.
Point it at a different role, if you want to reuse one
Syntax
,verification role [role]
Example
,verification role @verified
Run it bare to recreate the role if it's been deleted.
Repair it if something's gone missing
Syntax
,verification update
Re-posts the button if the message was deleted, re-applies the channel's permission overwrites,
and recreates the role if it's gone. It reports exactly what it changed: a deleted channel
is the one thing it won't recreate, since that would orphan the old row and lose the channel's
history; that case points you at reset + setup instead.
Syntax
,verification config
Syntax
,verification reset
Syntax
,verification button <message link> [button text]
Example
,verification button https://discord.com/channels/1/2/3 click to verify
reset disconnects verification without touching the role or channel: both stay in place, visible
and deletable by hand, in case you want to reuse them.
Why the role gets checked twice
Verification is gated on Manage Server, which is a fake-permission-grantable permission: a role can hold it inside Righteous without holding it in Discord. That means a role with no real Discord permissions could still be used to point the verify button at something dangerous, so the role you pick is checked twice, not once:
- When you set it (
,verification role), a role carrying Administrator, Manage Server, Manage Roles, Ban or Kick is refused outright. - Again, every time someone clicks the button. A role that was harmless when you stored it can be edited afterwards (Discord doesn't stop an admin from adding Administrator to an existing role), so the same check runs again at click time, on the role's current permissions, not the ones it had when you set it.
If a member clicks Verify and gets refused with a permissions message, that's this second check firing on a role that's changed since it was set: pick a role with no dangerous permissions and set it again.
Common issues
A returning member got their old roles back and nobody asked for that. That's role history, if
it's on, working as designed. See Restore roles when someone rejoins.
Turn it off with ,autorole history off if it's not wanted.
A returning member is muted/jailed/timed out again immediately, and didn't get their old roles back. The punishment was still active when they left, and rejoining doesn't clear it. That's the containment step described above, and it's deliberate: role history and autorole are both skipped for a member containment catches, so a fresh set of roles can't outrun the punishment that's about to land on them.
Autorole didn't apply a role. Check the role sits below the bot's own highest role in the role list: Discord silently refuses the assignment otherwise, and Righteous can't force it.
Verification won't hand out the role I picked. See Why the role gets checked twice: a role carrying a dangerous permission is refused, at setup and again at click time.
The verify button says "This interaction failed." Run ,verification update: it re-posts the
button and re-applies the channel's permissions in one pass, and tells you exactly what it fixed.