Add to Discord
Discord permissions confuse people because they look like a checklist and behave like a calculation. A member's access is not what any one role says — it is the result of combining every role they hold, then applying whatever the channel says on top. Once you can run that calculation in your head, the weird cases stop being weird.
The model in one page
Three things decide what somebody can do:
- Role permissions — server-wide. Everyone has
@everyone, plus whatever else they have been given. These stack: hold two roles and you get the union of both. - Channel overwrites — per channel. These override role permissions for that channel only, in either direction.
- Hierarchy — role position. Decides who can act on whom, which is a different question from what each person can do.
Almost every permission problem is one of those three doing exactly what it should while you were thinking about a different one.
The order Discord resolves it in
Is this the server owner?
Then everything is allowed, and nothing below runs. The owner cannot be locked out of their own server, which is worth remembering when you are testing.
Start with
@everyoneIts permissions are the baseline for every member, because every member has it. This is the one most people forget is a role at all.
Add every other role they hold
Permissions are combined, not replaced. If any role grants it, they have it — position does not matter here. A role cannot take a server-wide permission away from another role.
Do they have Administrator?
Then everything is allowed and channel overwrites are ignored entirely. This is why an admin can see a channel you explicitly denied them.
Apply the channel overwrites
In order: the
@everyoneoverwrite, then role overwrites (all the denies, then all the allows), then any overwrite set on that specific member. Later steps beat earlier ones, so a member-level allow wins over a role-level deny.
Roles stack and can only ever add. Channel overwrites are the only place a permission gets taken away.
Hierarchy — who can act on whom
A separate system, and the one that produces the "I have Administrator but it will not let me" complaints. Your position in the role list decides who you can affect.
- You can only manage roles below your own highest role. Not at the same height — below.
- You can only moderate members whose highest role is below your own. Two moderators at the same height cannot ban each other, which is usually what you want.
- The owner is above everyone, regardless of roles.
- A bot is bound by exactly the same rule. NeoBot cannot hand out, rename or recolour a role that sits at or above its own — not a limitation of the bot, a rule of the platform.
The four mistakes that cause almost everything
1. Handing out Administrator
Administrator is not "trusted staff". It is every permission, including ones that are not on the list yet, and it makes channel overwrites stop applying to that person entirely. Someone with Administrator can delete the server's channels, ban anyone below them, and remove your other moderators.
Almost nobody needs it. A moderator needs a specific short list, and giving that list explicitly is both safer and clearer:
| Permission | What it is for |
|---|---|
| Manage Messages | Delete and pin. The one they will use most. |
| Timeout Members | Stop someone talking without removing them. The right first action. |
| Kick Members | Remove someone who can come straight back. A message, not a barrier. |
| Ban Members | The real one. Consider keeping it for senior staff only. |
| Manage Nicknames | For fixing unreadable or offensive names. |
| View Audit Log | So they can see what other staff did. |
| Move Members | Voice moderation, if you have active voice channels. |
2. Forgetting that @everyone is a role
It is where the baseline lives, and it is the cleanest place to fix a whole class of problem. If you do not want new members creating invites, changing nicknames, or using external emoji, turn it off on @everyone once rather than trying to deny it per role later — which does not work anyway, because roles cannot subtract.
3. Locking a channel by denying a role instead of denying @everyone
To make a channel staff-only, deny View Channel to @everyone on that channel and allow it for the staff role. The instinct to deny it to @Member instead fails as soon as somebody exists who does not have @Member — a new joiner, a bot, someone whose roles got cleared.
4. Editing a channel and breaking category sync
Covered in the structure guide, and it belongs here too because it is the single most common source of "this one channel is wrong". Change permissions on a channel directly and it stops inheriting from its category, silently and permanently. Fixing it means re-syncing the channel — which discards its own overwrites — or setting the category-level change on it by hand.
A role setup that scales
The shape below works from twenty members to twenty thousand, because it keeps the number of roles that matter small no matter how many roles exist.
| Tier | Roles | Who assigns |
|---|---|---|
| Above the bot | Owner, Admin | You, rarely |
| The bot | @NeoBot and any other bot that assigns roles | Discord, when added — you move it |
| Staff | Moderator, maybe Helper | You, deliberately |
| Earned | Level rewards, Regular, Booster | Automatic |
| Chosen | Games, regions, pings, colours | The member, in one click |
The two rules that keep it working: nothing in the bottom two tiers grants a permission, and nothing above the bot needs to be handed out automatically. Break the first and a self-assignable role becomes a security hole. Break the second and your automation silently stops working.
Frequently asked
Why can a member see a channel I denied them?
Three likely causes, in order: they have Administrator, which ignores channel overwrites entirely; a different role of theirs has an explicit allow on that channel, which beats a role-level deny; or you denied a role they do not actually have. Use the member view in the channel's permission settings — it shows the resolved answer rather than the inputs.
Why will the bot not give someone a role?
Almost always hierarchy. A bot cannot assign a role at or above its own highest role. Drag the bot's role above the roles it needs to hand out. The second cause is a role that is managed by another integration — those cannot be assigned by anyone.
Does role order affect permissions?
Not for what a member can do — server-wide permissions are combined regardless of position. Order decides two other things: who can manage or moderate whom, and which colour a member's name takes (the highest role that has a colour set).
What is the difference between kick and ban?
A kick removes someone; they can rejoin immediately with any valid invite. A ban removes them and blocks their account from returning. For anything short of "never come back", a timeout is usually the better tool — it stops the behaviour, expires on its own, and creates far less drama.
How many roles should a server have?
As few permission roles as possible — usually two or three — and as many identity roles as are genuinely useful. Discord caps a server at 250, which nobody should be near for permission reasons. If a server has fifteen roles that grant something, nobody can answer "who can do what here", including you.
Can a role take a permission away?
No. Server-wide permissions only ever add — if any of a member's roles grants something, they have it. The only place a permission is removed is a channel overwrite, or a timeout.
Next
The practical application of all this is a role picker members use themselves: how to set up reaction roles covers the panel, the hierarchy check, and the choice between buttons, dropdowns and reactions.