How Discord Roles and Permissions Actually Work
Role hierarchy, permission bits, and channel overwrites — the three concepts that decide what any member or bot can actually do.
Quick answer
A Discord role grants permissions and sits at a position in the server's hierarchy. Whether a specific action is allowed comes down to three things together: the permission bits a member's roles grant, any channel-specific overwrite that allows or denies that permission there, and — for managing other members or roles — where the acting role sits in the hierarchy, regardless of what permissions it has.
What you'll learn
- What a role actually is — permissions plus a hierarchy position
- Why role order in the list matters as much as the permissions granted
- How channel overwrites can override the server-wide default
- Why Administrator doesn't bypass hierarchy
- How this affects both members and bots
Why role and permission confusion is so common
Discord's permission system does several genuinely different things under one 'roles' concept — granting abilities, ordering authority, and scoping access per channel — and conflating them is the single biggest source of 'why can't this person/bot do that' confusion in any server.
The three things a role actually controls
Understanding these as three separate mechanisms, not one, resolves most confusion immediately.
Permissions — what a role grants
Each role has a set of permission bits (Send Messages, Manage Roles, Ban Members, and so on). A member's effective permissions come from every role they hold, combined.
Hierarchy — who can manage whom
Roles have a position in an ordered list (Server Settings → Roles). A member or bot can only manage roles and members positioned below their own highest role — this is enforced independently of what permissions they have.
Channel overwrites — per-channel exceptions
A specific channel or category can allow or deny a permission for a specific role or member, overriding the server-wide default in either direction. A role can have Send Messages server-wide and still be denied it in one specific channel.
Why this matters for bots specifically
Every one of Airwavy's role-dependent features — verification, reaction roles, moderation, leveling reward roles — depends on getting this right, because a bot is subject to the exact same three rules a human member is.
- Airwavy's own role needs to sit above any role it's expected to grant or manage — including Administrator doesn't change this.
- A feature can have every Discord permission it needs and still fail if a specific channel's overwrite denies it there.
- This is why 'it has Administrator, why doesn't it work' is almost always actually a hierarchy or channel-overwrite issue, not a missing permission.
How to reason through a real permission problem
- Identify the exact action, the role or bot attempting it, and the target member/role/channel.
- Check what permission that action requires, and whether the acting role actually has it — server-wide.
- Check for a channel-specific overwrite that might deny it there even if the server-wide default allows it.
- For anything involving managing another role or member, compare hierarchy position — is the acting role actually above the target?
- Fix the layer that's actually failing, rather than granting broader permissions as a guess.
Common mistakes
- Granting Administrator to fix a permission problem instead of identifying which specific permission or hierarchy issue is actually blocking it.
- Forgetting that role order in the list is itself a permission mechanism, not just a visual sorting choice.
- Assuming a permission granted server-wide applies everywhere, without checking channel overwrites.
- Treating a bot's role placement as a one-time setup step instead of something to re-check after adding new roles.
Troubleshooting
A role or member can't be managed even with the right permission
Check hierarchy — the acting role has to sit above the target's highest role. Permission bits alone don't override this.
A permission works in one channel but not another
Check that channel's specific overwrites — they can deny a permission the server-wide default allows.
I'm not sure which permission a specific action needs
Check the command or feature's own reference documentation — each one lists its declared permission requirement explicitly.