The complete guide to Discord’s Permission System

Want to create the best possible Discord server? Struggling with permissions and overwrites? Does you muted role not work?

Then this guide is for you.

Discord offers an in-depth permission system, which you can use to customize who can do what in your server or in individual channels and categories.

Understanding how this system really works is the most important step when it comes to creating secure and efficient Discord servers.

Discord Permissions

There are lots of individual permissions in the server settings. I recommend you take a minute to get familiar with what each permission means and does before reading this guide.

You can find a good overview in the Discordapp Wiki

Important definitions

Before I jump into explanations, let me define and explain some important terms:

Server Owner

Each Discord server has one owner, by default, this is the user who created it. The server owner always has all the permissions, no matter which roles they have, note that they’re the only user able to delete the server.

The server ownership is limited to only one user at once but can be transferred in the Members tab of the server settings.

Be careful, this can not be undone which means whoever is the new server owner can delete it.

@everyone

If you head into your server settings and into the Roles tab, you’ll find the @everyone “Role”.

The permissions defined for @everyone apply to every user in your server, no matter if they have roles or not.

@everyone is not technically a role and is not treated the same as a role by Discord. You can read more about this in the “Permission Hierarchy” section later in this article.

By default, new roles inherit the permission settings of @everyone when created.

Roles

Roles are Discord’s main way of giving specific sets of permissions to specific members.

Say you only want a certain group of moderators to be able to kick or ban members. You would then create a role called “Moderators”, give that role the permission to kick and ban members.

Then, assign that role to all users you want to be moderators.

Role Order

Roles can be dragged and dropped in the Roles tab to change their order. This has multiple functions:

  • Some permissions, like “Manage Roles”, only allow users to change roles which are below their own highest role
  • The order of hoisted roles in the member list follows the order in the Roles Settings.
  • Roles can also be used in a purely cosmetic way to change the color of a user’s username.
    Every user has the color of the highest colored role assigned to them. If you have a yellow role and another role above it which has the default color, your name will be yellow

Generally, it is best to order the roles by power and importance from top to bottom.

Allow

If a permission is set to “Allow”, it is set to green for @everyone, a role or a user. This can be done in the server settings in the Roles tab, or in the category/channel settings as an override.

Allow on the Server Settings/Role Level

Allow on the Category/Channel Level

Deny

If a permission is set to “Deny”, it is set to red for @everyone, a role or a user. This can be done in the server settings in the Roles tab, or in the category/channel settings as an override.

Deny on the Server Settings/Role Level

Deny on the Category/Channel Level

Neutral/Inherit

If a permission is set to neutral/inherit (gray), it will inherit whatever permission is set on the server settings/role Level. Neutral can only be selected in the category/channel permission settings.

Neutral can only be set on the category/channel Level

Hoisted

A role is hoisted (Meaning it appears separately in the member list) if this setting is set to Allow in the server settings Roles tab:

This feature is used often to make it easier for users to find important people like staff members or moderators.

The Administrator Permission

Users with the “Administrator” Permission automatically have every other permission and are unaffected by category/channel overrides.

This permission should basically never be given to anyone unless you co-own the server.

Lots of bots request it by default, but it’s best to take it away from them for security reasons. Bots don’t usually need the permission anyway, they just add it to prevent permission issues (which you’ll know how to fix after reading this guide)

Categories

Text and voice channels are usually put into categories in Discord servers.

By default, each channel in a category is synced to that category. This means that if you change the permissions of that category the changes are going to apply to all synced channels in it.

You can unsync channels from their category by changing their individual permission settings.

Discord Permission Hierarchy

Let’s recap the most important points before I explain how the permission hierarchy works:

  • @everyone defines the default set of permissions which every user in the server has
  • Roles can be used to add or take away permissions from a user or group of users
  • Roles can also be used for purely cosmetic purposes

While this model explains the basics, many questions are still left unanswered.

What if a user has multiple roles that either deny or allow a certain permission? Do role permissions add up? How do overwrites work?

This is where the permission hierarchy comes into play. Discord wrote an official article to explain how it works, so let’s take a look at that:

1. Server Permissions

The Server Permissions are an individual’s server-wide set of permissions. This set of permissions is made up out of all the Allows that the user has through @everyone and all of his roles.

Let’s look at an example:

I set up a Server that has the Roles “Role 1” and “Role 2”. The permissions for @everyone, Role 1, and Role 2 are set up like this:

@everyone Permissions

Role 1 Permissions

Role 2 Permissions

If a user has the Roles Role 1 and Role 2, what are his Server Permissions?

Well, according to the Discord article, the Server Permissions are the sum of all the allows for all the roles a user has + the allows for @everyone.

In this case, the user has the permissions

  • Send Messages
  • Read Message History

because of @everyone,

  • Attach Files

because of Role 1, and

  • Embed links

because of Role 2. All of these permissions together add up to create the user’s Server Permissions.

As you can see, permissions like “Mention @everyone, @here and all Roles” are not part of this individual user’s set of Server Permissions as he has no allows for them in any of his roles or @everyone.

2. Category/Channel Permissions

With Server Permissions you can control which group of users can do what in the whole server. But what if you want certain groups do be able to see hidden channels or only allow a certain role to write messages in a specific category?

That’s where more granular control is needed. Discord allows this through its Category and Channel Permissions.

This might seem complicated at first, but it’s really intuitive to use once you understand it.

When you create a new channel, each of the permissions is set to Neutral/Inherit by default. This means that the user will simply have their Server Permissions in that channel.

However, if overwrites are set on the category/channel permission level, the hierarchy above becomes important. Let’s expand our example from the Server Permissions part:

Let’s say we have a text channel called “#general” in the “Text Channels” category in our Server. The User “M0m” has the roles “Role 1” and “Role 2” from the Server Permissions section.

By default, “M0m” can Send Messages, Read the Message History, Attach Files and Embed links in the #general channel as those are the user’s Server Permissions.

Now, let’s add some overwrites to the “Text Channels” category (#general is synced to the category in this example)

Let’s start by adding denies for the “Embed Links” and the “Attach Files” Permission of @everyone.

M0m can now only Send Messages and Read the Message History in #general.

Why?

Because according to the Channel permission hierarchy, the denies of @everyone in #general are applied after the Server Permissions.

Now, let’s add some overwrites to Role 1 in the category:

“Embed Links” and “Attach Files” are now set to Allow for Role 1.

M0m can now Send Messages, Read the Message history, Attach Files and Embed Links in #general.

Why?

Because all the allows of a member’s roles are added after the Server Permissions and after the settings for @everyone.

Next, let’s add a set of overwrites for Role 2 on top of all overwrites we currently have:

“Embed Links” and “Attach Files” are now set to Deny for Role 2.

M0m can now Send Messages, Read the Message history, Attach Files and Embed Links in #general.

Why?

Because all the allows of a member’s roles are added after the Server Permissions, after the settings for @everyone, and after all of the denies of a member’s roles.

This is important to know because Allows of a lower role will overwrite denies of a higher role. However, Allows set for @everyone will not overwrite denies of any role on the category/channel level!

Now for the last overwrite, let’s add some user-specific settings to the category:

“Embed Links” and “Attach Files” are now set to Deny for the user M0m.

M0m can now only Send Messages and Read the Message History in #general.

This is because user-specific overwrites are applied after the Server Permissions, after the settings for @everyone, and after all of the overwrites for a member’s roles.

Best Practices

Now that you have a solid understanding of how Discord permissions actually work, let’s dive into some best practices you should implement in your servers!

Important changes to the default @everyone

The default permissions set for @everyone in the server role settings are generally fine. However, one change I definitely recommend is setting “Mention @everyone, @here, and all Roles” to deny for @everyone and all roles who aren’t Moderators/Administrators.

How to figure out the most efficient permission system for your server

The goal of permission best practices is essentially to get the job done with as little changes from the default state as possible. You only want to set a permission if it is necessary. Example:

If a user does not have the “Embed Link” permission in his Server Permission, then there is no need to overwrite it with a deny in the Category/Channel Permissions, as the user doesn’t have that permission anyway.

Having optimal permissions means having the least amount of Category/Channel overwrites required to achieve the permissions you want.

User-specific overwrites should basically never be used aside from very specific use cases.

A good way of setting up server permissions is to ask: Do the users with this role need this specific permission in more channels/categories than they won’t need it in? Then decide based on that whether setting it to allow or deny is more efficient in terms of required overrides on the channel/category level.

To find an example of a Server using best practices with announcement channels, a hidden staff category, and a hidden category for users, please study my Server Template in the “Common Roles and example of Permission best practices in use” section further down.

Important denies for a Muted Role

If you have a Muted role in your Server, make sure it has Deny overwrites for these permissions:

  • Send Messages
  • Add Reactions (To prevent spelling of insults etc. through reactions)
  • Connect
  • Speak

Muted roles often don’t work because server owners don’t understand the permission hierarchy. Make sure the user has no Allows on the role or user-specific level in the Category/Channel settings which will overwrite the denies of the Muted role.

Redundant Denies

A lot of permission settings are redundant. For example, if a user can’t send messages in a channel, it is unnecessary to also deny the “Embed Links” or “Attach Files” permissions as the user won’t be able to send any messages anyway (See Important Denies for a Muted role).

Also, if a user can not read a text/voice channel or messages in a channel, that means that the user can not see the channel at all. If a user can’t see a channel at all, it is unnecessary to deny any other permission.

Vanity and Color Roles

If you have vanity or color roles it is best practice to scroll to the bottom of their settings in the Server Settings Roles tab and press “Clear Role Permissions”. User don’t need any special permissions through these roles and if you clear them they won’t become a hassle if you ever decide to make changes to @everyone.

Personal Preferences

Should a muted user be able to create invites? what perms do moderators / Administrators really need? Is it better to have a hoisted Staff role instead of hoisting Moderators and Administrators?

These are questions that don’t really have a right or wrong answer. A lot of settings on Discord depend on the specific Server and situation you’re dealing with and over time you’ll develop your own style of running Discord Servers.

Common Roles and example of Permission best practices in use

Most servers will have the following Roles

  • Administrators
  • Bots (optional)
  • Moderators
  • Muted

I have created a Server Template that incorporates all of these roles as well as examples for permission best practices.

You can use the template for your server by clicking here!

That’s it for this complete guide on Discord Permissions. I hope I could answer all of your questions and give you an in-depth understanding of how the system works.

If you have any other questions, please let me know in the comments down below. Also, make sure to check out my other Discord guides on this website. I recommend my guide on how to add Role categories to your Discord Server!

Add comment

>

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.

Privacy Settings saved!
Privacy Settings

When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.

These cookies are necessary for the website to function and cannot be switched off in our systems.

In order to use this website we use the following technically required cookies
  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

For perfomance reasons we use Cloudflare as a CDN network. This saves a cookie "__cfduid" to apply security settings on a per-client basis. This cookie is strictly necessary for Cloudflare's security features and cannot be turned off.
  • __cfduid

Decline all Services
Accept all Services