Discord role hierarchy, explained properly

Discord’s permission system has two layers, and people learn the wrong one first.

The layer everyone learns is the checkbox: does this role have Manage Roles or not. The layer that actually decides most outcomes is position — where a role sits in the vertical list. Position beats permission, every time.

Before you start: you need Manage Roles to follow along, and you need to be able to see Server Settings → Roles.

The rule in one sentence

A member can only act on roles positioned below their own highest role.

That is it. Manage Roles does not mean “manage all roles” — it means “manage roles beneath me.” A moderator with Manage Roles cannot assign a role sitting above their own, cannot remove it from anyone, and cannot edit it. The permission is real; the reach is bounded by position.

The same bound governs moderation actions. Kick, ban and timeout all require that the target’s highest role sits below yours. A moderator cannot time out an administrator, no matter what their permission set says.

It is the highest role that counts, not the role carrying the permission. A moderator whose Manage Roles sits on a low staff role but who also holds a decorative role near the top is judged by the decorative one. This is why granting someone a colour role occasionally expands what they can moderate, entirely by accident.

Why your bot cannot assign a role

This is the single most common Discord support question, and it is nearly always position.

A bot has a role, created automatically when it was invited. If that role sits below the role the bot is trying to hand out, the assignment fails — regardless of whether the bot has Manage Roles.

The fix is to drag the bot’s role above every role it needs to assign. Nothing else needs to change. No permission needs adding.

Bots you invite later are placed lower in the list than bots invited earlier. A bot that worked yesterday can fail today because someone added a role above it.

Permissions combine; they do not override

A member’s effective server-level permissions are the union of every role they hold. Roles do not override one another at server level — there is no “my higher role says no, so no.”

If any role a member holds grants Manage Messages, they have Manage Messages. Removing it from one role achieves nothing if another still grants it. This trips people up because position governs actions on roles but not the combination of permissions, and those feel like they should work the same way.

Channel overrides are the exception

Channel-level overrides are the one place a deny genuinely wins.

The resolution order, simplified but accurate enough to work with:

1. Server-level permissions from all roles are combined.
2. The @everyone channel override is applied.
3. Role overrides on the channel are applied — all denies, then all allows.
4. The member-specific override on that channel is applied last, and beats everything above it.

So a red cross on a role at channel level defeats a green tick on that role at server level. And a member-specific allow defeats a role-level deny. This is why “the permission is on but they still cannot see the channel” is almost always a channel override, not a server permission.

Worked example

A member holds @everyone, Member and Contributor. The channel is #proposals.

The member can post. Remove Contributor and they cannot — not because anything about them changed at server level, but because the channel’s @everyone deny is no longer being overridden.

This pattern — deny to @everyone at channel level, allow back to one specific role — is how nearly every private or restricted channel on Discord is built, and reading the table top to bottom is the fastest way to debug one.

Administrator ignores all of it

A role with Administrator has every permission everywhere, and channel overrides do not restrain it. The only thing that still applies is position — an administrator still cannot act on a role above their own, and cannot touch the server owner.

Which is the argument against handing it out. Administrator is not “trusted staff”; it is “can delete every channel.” Grant the specific permissions instead, even though it takes longer.

One exception worth knowing: a member with Administrator cannot be timed out by anyone, regardless of position. Kick, ban and role changes still work against them from above; timeout does not. That single carve-out accounts for a large share of “the timeout command is broken” reports.

Two ceilings that look like permission faults

250 roles per server. Attempting to create the 251st fails with error 30005 while every permission involved is correct. A bot creating roles automatically — colour roles, level roles, per-event roles — is the usual way a server reaches it without noticing.

28 days is the maximum timeout. A request for longer is rejected rather than clamped. Anything beyond that is a kick or a ban, not a timeout.

Both produce failures that look like a hierarchy problem and are not, which is why they are worth ruling out before rearranging anything.

What happens when a role is deleted

Deleting a role removes it from every member instantly and cannot be undone — Discord keeps no recycle bin for roles, and recreating one with the same name and colour does not restore who held it.

Two consequences follow. Channel overrides referencing that role disappear with it, so a private channel built on “deny @everyone, allow Staff” becomes invisible to everyone when Staff is deleted. And every position below it shifts up by one, which can quietly move a cosmetic role above a bot.

The safe sequence is to strip the role’s permissions first, confirm nothing breaks over a day, and only then delete it.

Reordering safely

Dragging one role changes the position of every role beneath it, which is why hierarchy problems appear after a change nobody thinks was related.

Three habits make it survivable:

Move the role, then test the bot immediately. The failure is silent, so it is only caught by looking.

Keep a gap above the bots. Leaving a couple of unused positions above your role-managing bots means adding a new staff role does not require re-checking every automation.

Know that role updates are recorded. Discord’s audit log retains role create, update and delete entries for 45 days, so “who moved this” is answerable — and a bot logging role events keeps that answer past Discord’s window. Vetox records role creation, deletion and updates among its 148 log event types, free on every tier.

A layout that avoids the problem

Order roles from most to least privileged, top to bottom:

1. Bots that assign roles — above everything they manage
2. Owner / Administrator
3. Moderators
4. Trusted or veteran member roles
5. Level and reward roles
6. Self-assignable and cosmetic roles
7. @everyone

Put every bot that manages roles above the roles it manages, and put cosmetic roles at the bottom where nothing needs to act on them.

If you use automatic role rewards — level roles, streak roles, roles granted on join — the granting bot’s role must sit above all of them. Any bot that hands out roles is subject to the same rule; a dashboard makes the ordering easier to see, but it does not exempt the bot from position.

Where this shows up across a multi-system bot

Every Vetox system that grants a role — self-roles, auto-roles, rank rewards, streak milestones — runs the exact same Discord check, because the check belongs to the platform, not to the feature. Get the bot’s position right once and it is right for all of them at the same time; get it wrong and every one of them fails silently in the same way, which is why “half my automated roles have stopped working” is almost always one bot sitting in the wrong place rather than four separate faults.

One behaviour is worth knowing if you run into this: Vetox’s Leveling and Streaks re-evaluate a member’s reward roles on every XP award or streak tick, not only at the moment a threshold is first crossed. Fixing the bot’s position does not just unblock new awards going forward — it backfills anyone who was owed a role while the position was wrong, on their next qualifying action, with nothing to reset by hand.

Checking it quickly

Server Settings → Roles, then look at the vertical order. Ask two questions:

1. Is every role-managing bot above every role it hands out?
2. Is anything cosmetic sitting above something privileged?

Most hierarchy problems are visible in ten seconds from that screen, without opening a single permission tab.

Frequently asked questions

Does Administrator bypass role position? No. It bypasses permission checks and channel overrides, not position — and never the server owner.

Why can a moderator not time out an admin? A member with Administrator cannot be timed out by anyone, whatever their position.

Can two roles share a position? Effectively they are ordered by internal ID when positions collide, which is unpredictable from the interface. Give roles distinct positions rather than relying on it.

How many roles can a server have? 250. The 251st fails with error 30005 even when permissions are correct.

Does deleting a role remove its channel overrides? Yes, and a private channel built on that role becomes visible or invisible accordingly. Strip its permissions first and wait a day.