Discord Permissions Explained: Role Hierarchy, Channel Overwrites and the Order They Apply

Discord permissions feel unpredictable because two independent systems are being combined, and almost nobody reads the order in which they combine. Once you know the order, the behaviour becomes completely deterministic and most permission bugs become obvious rather than mysterious.

Two systems, not one

The first system is server-level permissions. Every role carries a set of permission flags, stored as a bitfield, and a member holds the union of all their roles' flags. This is additive: if any role grants "Manage Messages", the member has it server-wide. There is no way to subtract a permission at this level.

The second system is channel overwrites. Each channel can carry allow and deny entries for individual roles and individual members. This is the only place where a permission can be taken away. Understanding that subtraction only exists at channel level explains most of the confusion people have with the system.

The exact order of evaluation

Discord's developer documentation specifies the sequence precisely. Base permissions for @everyone are applied at server level. Permissions from the member's roles are added at server level. Then, at channel level: @everyone denies, @everyone allows, role denies, role allows, member-specific denies, and finally member-specific allows.

Two consequences follow immediately. Allows beat denies at the same level, because the allow is applied afterwards. And member-specific overwrites beat every role-based rule, which makes them a convenient exception mechanism and a terrible default habit — a member overwrite is invisible in your role design and will be forgotten within a month.

Administrator is not a permission, it is a bypass

The documentation is blunt about this: Administrator "allows all permissions and bypasses channel permission overwrites". The evaluation short-circuits — if the member has it, the calculation returns everything and never reaches the overwrite stage at all.

This means an admin cannot be excluded from a private channel, cannot be rate-limited by slowmode rules you have set, and cannot be safely used to test whether your permission model works. It also means every Administrator role is a full compromise of the server if that account is taken over. Give moderators the specific flags they need instead; the extra ten minutes of setup is the cheapest security you will ever buy.

Role hierarchy applies to actions, not to visibility

This is the single most common misconception. The vertical order of roles in server settings determines who can moderate whom: a member can only kick, ban, or edit roles below their own highest role. It does not determine which permission wins in a channel. The order of roles in a channel's permission list has no priority meaning at all.

So if a member has both a "Muted" role that denies sending messages in a channel and a "Member" role that allows it, hierarchy does not decide the outcome — the evaluation order does, and the allow applied later wins. This is why mute roles must deny at the channel level and must not be counteracted by an allow on any other role the member holds.

Design the model before you click anything

A role model that survives growth separates three things that servers habitually merge. Access roles decide what a member can see. Identity roles are cosmetic or self-assigned and carry no permissions. Staff roles carry capability. Keeping these separate means you can hand out a colour role without accidentally granting access, and you can restructure access without touching anyone's identity.

Set @everyone as your baseline and treat it as the definition of "what a stranger may do". In a gated server, that is close to nothing. Then each access role only ever adds. If you find yourself denying things to @everyone in twenty separate channels, your baseline is wrong and should be tightened at the server level instead.

The permissions that deserve a second look

A handful of flags are far more dangerous than they look. "Manage Roles" lets a holder grant any permission below their own highest role, which is a privilege-escalation path. "Manage Webhooks" allows creating an endpoint that posts as anyone. "Mention @everyone" is a spam amplifier if a moderator account is compromised. "Manage Channels" allows deleting the evidence of everything else.

None of these should sit on a broadly assigned role, and every account holding them should have two-factor authentication enabled — Discord requires 2FA for moderators on servers that want to be listed in Discovery, and it is a sensible requirement independent of that.

Testing it properly

Discord's own permission preview in channel settings will answer "what can this role see here", but it will not catch interactions across roles. The reliable test is an account with no roles at all and a second account with exactly the role you are validating. Ten minutes with two test accounts finds more problems than an hour of reading the settings panel.

Finally, write the model down. A short document listing each role, what it grants, and which category it opens is the difference between a server that can be handed to a new moderator and one that only its builder understands. If nobody can reconstruct why a permission exists, it will eventually be removed by someone tidying up, and something will quietly break.

Categories, inheritance and synced channels

A channel created inside a category copies that category’s overwrites at the moment of creation and is then marked as synced. While it stays synced, later changes to the category propagate to it. The moment you edit that channel’s permissions directly, it desynchronises and stops receiving category changes — silently, with only a small indicator in the interface.

This is the mechanism behind the most common permission complaint: an admin changes a category, eleven channels update, one does not, and nobody remembers that this one channel was tweaked six months ago. The discipline that avoids it is to make every access decision at category level, and to treat a desynchronised channel as a documented exception rather than a convenience.

A worked example

Consider a member with the roles Member and Contributor in a channel where @everyone is denied Send Messages, Member is allowed Send Messages, and the member has a personal deny for Send Messages because they were muted. Evaluation runs: base @everyone permissions, then the union of Member and Contributor at server level, then the @everyone channel deny, then the @everyone channel allow, then role denies, then role allows — which re-enables sending — and finally member denies, which removes it again.

The member cannot post, and the reason is the last step rather than the first. Change one detail — make the mute a role deny instead of a member deny — and the role allow on Member, applied afterwards, wins and the mute silently fails. This is why mute roles are implemented as member-level or as a deny on a role positioned so that no other role re-allows the same permission in that channel.

Bots have roles, and their position matters

A bot is a member with a role, and it is bound by the same hierarchy rule as a human: it can only assign or remove roles that sit below its own highest role. The single most common bot support ticket in existence is a role assignment failing because the bot role was dragged below the role it is supposed to grant.

Two habits prevent it. Keep bot roles immediately below your staff roles and above everything they manage, and never reorder roles without checking what the bots need to reach. A bot that has silently stopped assigning roles will not usually announce the failure — members simply stop receiving them.

Fixing a permission model that is already broken

Rebuilding permissions on a live server is risky in one specific way: for a few minutes, people can see things they should not. The order that minimises exposure is to tighten the baseline first and open up afterwards. Set @everyone at server level to the minimum, verify that the private categories are still private, then add the access roles back one at a time.

Do the work with a written target model rather than by clicking through the interface, and check each step with a test account that holds exactly one role. Expect the process to surface at least one channel with a forgotten member-level overwrite; that is normal, and finding it is the point of the exercise.

Two-factor authentication is a server-level setting

Discord offers a server setting that requires two-factor authentication for any member performing moderation actions. Turning it on does not weaken anything and closes the most realistic attack path against a community: not a clever exploit, but a moderator account with a reused password.

The requirement also appears in Discord’s criteria for Server Discovery, so a server that intends to be publicly listed will need it regardless. Enabling it early is easier than retrofitting it once a dozen people hold moderation roles.