11 min read · Published 2026-11-01 · Updated 2026-11-01 · Perminator
When a permission "does not work," Discord is almost always doing something specific and documented. The interface just does not say which rule won. Work down the checks below before you start toggling at random. Changing five overrides to fix one symptom is how private channels start leaking. The calculation order itself is in channel permission overrides . Flag-by-flag notes are in the permission reference .
Before you change anything
Write down the member, the role list they hold, the channel, and the thing they can or cannot do. Open Server Settings → Roles and confirm which role is their highest. Open the channel's Permissions tab and look at @everyone, each of their roles, and any member-specific row with their name on it. Then check whether any of their roles has Administrator. If it does, stop: overrides are not the bug.
Change one setting, retest with that member, and write down the result. If you are testing with your own owner account, you will not see the bug. Owners bypass the hierarchy. Use a spare account or ask the member to retry.
Where to look first
Match the symptom, then read the section under it. Do not start with Administrator.
What you see
First check
Kick, ban, or timeout fails
Role order, not the permission toggle
A private channel is visible
Administrator, then @everyone, then an allow on another role
A "muted" role does nothing
Server permissions are additive. A role cannot subtract.
Bot fails to assign a role
The bot's role is below the role it is assigning
Timeout does nothing
The target is above the moderator, or has Administrator
Manage Channels is on, but one channel is frozen
That channel denies Manage Permissions for their role
A brand-new role sees staff rooms
You denied View Channel per role instead of on @everyone
No admin role, but they see everything
Some other role has Administrator, or they are the owner
They cannot kick, ban, or timeout
Confirm the role really has Kick Members, Ban Members, or Timeout Members. Then compare role positions. A moderator can only use those actions on a member whose highest role is strictly below the moderator's highest role. Equal roles cannot act on each other. Administrator does not lift this rule.
The same rule binds bots. If the moderation bot's role is under Moderator, it cannot time out a moderator, and the button will fail with a generic error. Move the bot role up, or accept that moderators are outside its reach. Both are reasonable. Leaving the bot under them and then granting it Administrator to "fix" the error is how the bot ends up above you.
A private channel is visible to the wrong people
Look for Administrator on any role the member holds. Administrator does not consult channel overrides. That includes private categories, the mod log, and ticket channels.
If they do not have Administrator, open the channel and read the overrides in order. An allow on any of their roles beats a deny on any other of their roles. Staff denied, Event Host allowed, and a member who holds both can see the channel. A member-specific allow beats everything except Administrator.
Then check the category. If the channel is synced, you are looking at the category's rules. If someone edited the channel and it is no longer synced, it kept a copy of the rules from that moment and ignored every category change since. The channel that "should" be private often is the unsynced one.
A deny role does nothing
At the server level, permissions only add. A Muted role with every toggle switched off grants nothing and removes nothing. The member's other roles still apply. To stop them speaking you either time them out, which is the tool Discord built for this, or you add a channel deny for that role on Send Messages. Even then, an allow for a different role they hold wins at the same layer.
People keep rebuilding the Muted role because it feels like it should work. It will not. Retire it and use timeouts. The difference between timeout, kick, and ban is covered in choosing a moderation action .
A bot cannot assign a role
Open the role list and find the bot's managed role. The role it is trying to hand out must be below that managed role. Reaction-role and level bots fail silently or with a permissions error when this is backwards, and the usual "fix" in their documentation is to drag the bot role up. Drag it up only as far as the highest role it is allowed to assign, not to the top of the server.
The bot also needs Manage Roles, and it can only grant permissions it itself has if it is editing a role rather than merely assigning it. A welcome bot that only needs to say hello does not need Manage Roles at all. Take the invite URL it offered you and remove permissions before you approve it.
Timeout does nothing
Timeout Members cannot be used on someone with Administrator, or on someone whose highest role is equal or higher. The timeout may appear to apply and then not restrict them, or the action may be rejected. Check both before you file a bug against a bot.
A timeout also has a clock. The maximum is 28 days, and anyone with Timeout Members can clear it early. If "they are still talking," look at the audit log for a timeout removal, not only for the timeout itself. The log keeps entries for 45 days.
Manage Channels is on, but one channel will not budge
Server-level Manage Channels can be removed on a single channel by a deny overwrite for Manage Permissions (the Manage Roles flag) or for Manage Channels. Staff categories sometimes deny both for the moderator role so moderators can talk there without being able to delete the category. That is a reasonable lock, and it looks exactly like a broken permission.
Check the channel, then the category if the channel is synced. If the deny is intentional, leave it and tell the moderator to ask an admin. If you remove the deny, you have also given them the ability to rewrite who sees that channel.
A new role can see the staff rooms
This happens when private channels were built by denying View Channel on every existing role and never denying @everyone. A new role has no deny, so it inherits the default allow. Fix the channel by denying View Channel for @everyone and allowing it for the staff roles that should remain. Remove the per-role denies afterward so the next role does not depend on them.
Do this from an account that will still be able to see the channel when you are done. The owner always can. A non-owner admin who denies their own last path back has to ask the owner.
Nobody admits to being an admin, but someone sees everything
Search roles for the Administrator toggle, not for a role named Admin. Cosmetic roles, "bots," and a role named after a retired founder are the usual hiding places. Also check the member's role list for a managed bot role if you are debugging a bot, and remember the server owner sees every channel regardless of overrides.
When you find the flag, turn it off and replace it with the specific permissions that job needs. Then retest the private channel. Until Administrator is off, no override edit will matter.
Change one thing, then retest
After the fix, look at the audit log entry so you know it saved, and ask the affected member to switch servers or reopen the client if a channel's visibility is cached. Record what the cause was. The next person to break it will be you, in three months, and the note is cheaper than another afternoon of overrides.
