Discord permissions: role hierarchy and overwrites

Almost every Discord permission problem is one of three things: a role sitting in the wrong position, a channel overwrite you forgot about, or Administrator quietly making a permission check meaningless. This is a reference for the moment you are staring at "Missing Permissions" and cannot work out why.

The three layers

Discord resolves permissions in three separate systems. They interact, and confusing them is the root of most problems.

1. Server-wide role permissions. What a role can do anywhere in the server. Set in Server Settings, Roles.
2. Channel overwrites. Per-channel adjustments that add or remove permissions for a role or a specific member. Set in a channel's Edit Channel, Permissions tab.
3. Role hierarchy. Which roles you are allowed to point an action at. Set by dragging roles up and down in Server Settings, Roles.

Layer 1 and 2 decide what you can do. Layer 3 decides who you can do it to. A member can hold Ban Members and still be unable to ban a specific person. That is not a bug.

Layer 1: server-wide permissions are additive

Every member holds @everyone plus whatever roles they have been given. Their server-wide permissions are the union of all of them.

Additive means there is no server-wide deny. Unchecking Send Messages on a role does not take that permission away from someone who also has another role that grants it. If you want to remove a permission from a member, you either remove the role that grants it, or you deny it at the channel level.

This surprises people who expect role order to break ties. It does not. Role position has nothing to do with server-wide permission resolution. A permission granted by any role the member holds is granted, regardless of where that role sits.

Layer 2: channel overwrites, in exact order

An overwrite is a per-channel allow or deny attached to a role or to a specific member. Each permission in an overwrite is in one of three states: allow, deny, or neutral (inherit). Neutral is the default and it is not the same as deny.

Discord computes a member's permissions in a channel by starting from their server-wide permissions and then applying overwrites in this order:

1. The @everyone overwrite's denies
2. The @everyone overwrite's allows
3. The combined denies of every role overwrite that applies to the member
4. The combined allows of every role overwrite that applies to the member
5. The member-specific overwrite's deny
6. The member-specific overwrite's allow

That list explains almost everything.

Later steps win. A role allow (step 4) beats an @everyone deny (step 1). This is exactly how a private channel works: deny @everyone view, allow the Moderator role view.

Role allows beat role denies. All role denies are applied together, then all role allows. If a member has one role denying Send Messages and another allowing it in the same channel, they can send. Role order does not break this tie either. A member-level deny is the only thing that reliably shuts one specific person out of one specific channel.

Member overwrites beat everything. Steps 5 and 6 are last, so a member-specific overwrite overrides any role-based one.

Category sync is not a permission

Channels created inside a category inherit the category's overwrites at creation time. After that, they are separate. Editing the category updates synced children, but a channel that has been edited individually is desynced and stops following the parent.

When someone says "I set it on the category and it did not apply", this is why. Check the channel itself. In the Discord UI, a synced channel shows the sync indicator in its permissions tab.

Category sync also cuts the other way: a grant applied to a category reaches every channel synced to it. If you are opening access broadly with an exception, apply the exception's deny first, confirm it, and only then apply the broad grant. Otherwise the excluded channel is briefly open, and fixing it afterwards does not undo the exposure.

View Channel is special

Denying View Channel hides the channel from the member entirely. Every other permission in that channel becomes irrelevant, because they cannot see it to use it. When a channel is invisible to someone who should see it, start here and work outwards.

Layer 3: hierarchy, and why your bot cannot assign that role

Hierarchy is the rule people hit and misdiagnose most often. The rule is short:

You can only manage a role that is positioned below your own highest role. You can only act on a member whose highest role is below your own highest role.

This applies identically to humans and bots. Manage Roles does not mean "manage all roles". It means "manage roles below mine".

So:

• A bot cannot assign a role positioned above its own highest role, even with Manage Roles and even with Administrator.
• A bot cannot kick, ban, or rename a member whose highest role is above the bot's own.
• A bot cannot grant a permission it does not itself hold. A bot without Manage Webhooks cannot create a role with Manage Webhooks.
• The server owner is outside the hierarchy entirely and cannot be acted on by anyone.
• Timeouts throw an error against anyone holding Administrator, and against the owner, no matter what the caller holds.

The fix is almost always "drag the bot's role higher." Server Settings, Roles, grab the bot's role, drop it above the roles it needs to hand out. Not above your admin roles; just above its targets.

A useful habit: put bot roles in a block near the top of the hierarchy but below your own staff roles, so a compromised or misbehaving bot still cannot touch your admins.

Administrator, and why it is dangerous

Administrator grants every permission in the server and bypasses all channel overwrites. There is no such thing as a private channel from a member with Administrator. Deny them View Channel on your staff-only channel and they can still read it.

That is the whole problem. Administrator is not "a lot of permissions", it is "the permission system does not apply to this account". A bot with Administrator can:

• Read every channel, including the ones you locked
• Delete every channel and category
• Create, edit, and delete every role below its own position
• Ban every member below its own position
• Change server settings, the vanity URL, and integrations
• Create webhooks anywhere, which keep working after the bot is removed

Three practical consequences:

"I'll just give it Administrator to make it work" skips every check, which also means you never find out which permission was actually missing.

Removing the bot does not undo what it did. Deleted channels stay deleted. Webhooks it created stay live. Roles it edited stay edited.

Hierarchy is your only remaining protection. Administrator still respects role position, so a bot holding it should sit below your staff roles.

Turn on the 2FA requirement for moderation in Server Settings, Safety Setup. It forces anyone performing moderation actions to have two-factor authentication on their own account, which limits the damage from one compromised moderator.

What least privilege looks like for a bot

Grant the specific permissions the bot's jobs need. Discord's invite link has a permissions parameter, and you can also edit the bot's role afterwards.

Two things worth knowing about that table. Manage Roles covers both role management and channel overwrites, which is why it looks broader than it sounds. And a bot needs View Channel on a channel to do anything in it at all, so a blanket @everyone deny on a category can silently lock the bot out of every channel under it unless the bot's own role has an explicit allow.

Debugging in five minutes

Work down this list in order. Stop at the first one that explains the symptom.

1. Is it hierarchy? Compare the actor's highest role position against the target role or the target member's highest role. If the target is higher, nothing else matters. This covers roughly half of all "the bot is broken" reports.
2. Is it Administrator on the wrong side? If the target holds Administrator, timeouts fail outright and channel-level restrictions on them do nothing.
3. Is it a channel overwrite? Open the channel's Permissions tab and read the actual overwrites, not the role's server-wide settings. Check @everyone first, then each role the member holds, then the member individually.
4. Is View Channel denied? If so, everything else in that channel is moot.
5. Is the channel desynced from its category? If you configured the category, check whether this specific channel is still following it.
6. Is it a neutral you assumed was an allow? Neutral inherits. On a channel where @everyone is denied, neutral for a role means denied.
7. Is it a Discord platform rule rather than a permission? Some failures are not permission failures. Bulk message deletion refuses anything older than 14 days regardless of permissions. Servers cap at 500 channels, 50 channels per category, and 250 roles. Slash command visibility settings in Server Settings, Integrations only hide a command from the picker; they are not access control.
8. Is 2FA required? If the server requires 2FA for moderation, an account without 2FA gets a permission error on moderation actions even when the role grants them.

The audit worth doing once a year

Open Server Settings, Roles and ask three questions about each role:

• Does anything here hold Administrator that does not need to? Every Administrator role is a full bypass of everything below it.
• Does any role held by ordinary members hold Manage Roles, Manage Channels, Manage Server, Manage Webhooks, or Mention Everyone? Those five are the ones that turn a regular member into an effective admin.
• Are the bot roles below your staff roles?

Then open your private channels and confirm the @everyone deny is actually on each one, rather than assumed from the category.

One note on bots that change permissions for you

If you use a bot to manage permissions, the property to look for is that it checks the asking member's permissions, not just its own. A bot that will happily set any overwrite for anyone who can type is a privilege escalation path: a member with no Manage Roles can ask the bot to do what they cannot.

Bond, which reads these permission bits back for you, works this way by design. It checks the requester's own Discord permissions and role position before acting, never requests Administrator (every action maps to a specific Discord permission), and treats widening @everyone access as its own confirmation step, separate from any standing approval. Asking it @Bond which roles can ban or kick, and what changed in the audit log this week? reads the real permission bits rather than guessing from role names.

That pattern is worth looking for in any admin bot, not just this one. There is a longer checklist in are Discord admin bots safe.

Related reading

• How to set up a Discord server with AI
• Are Discord admin bots safe? A permissions checklist
• Make a private or staff-only channel
• Add or remove a role from everyone