Setting Up Your Discord Permission System

Introduction

Discord's permissions have always been a pain point for new users and veterans alike. There's historically been plenty of unintuitive, inconvenient, or otherwise just undocumented behavior. This article is meant to give an overview of what the current best practices are.

Structurally speaking, Discord's permissions are controlled by 2 core concepts: roles and channel overwrites. We'll go over both concepts and explain all the little nuances. If you'd like a tl;dr, follow the chart below from top-down.

Role permissions

Roles are the backbone of controlling what users can do in your community, and luckily they're also the simplest to understand. Role permissions are purely additive, meaning that if a user has roles X, Y, and Z, they'll have all the permissions offered by those roles.

We wish that was the full story, though, because how you can use those permissions on other users is comparative, meaning that you won't be able to timeout, kick, ban, or generally manage a user whose highest role is higher than yours. To make matters more confusing, you will however be able to add or remove roles from them as long as the roles are lower than your highest one.

One thing you should note here is that the Manage Roles permission can be all-powerful, and you need to be very cautious of your role hierarchy because of it. For instance, let's assume you have a role named Admin with the Administrator permission. One day, you want to set up a bot that enables your users to assign pronoun roles to themselves. You invite the bot, grant it the Manage Roles permission, and lazily move it to the top of your member list. The bot is now able to escalate permissions by giving itself the Admin role.

If you want sustainable and easy-to-manage role permissions in your server, start with the @everyone role. Grant it exactly what you want all your members to have. If there's something you only want to enable on a per-channel basis, we recommend considering disabling it per channel instead, depending on how many channels need it enabled.

It's time to move up now. Go over your roles, hit the "Clear Permissions" button, then add back solely what that role needs - since, let's be real, your pronoun roles probably don't need "Embed Links" explicitly enabled. We do this to ensure that changing permissions for @everyone is easy in the future and doesn't require you to go over every single role, also leaving room for mistakes.

If you've followed along, your roles hierarchy should already be much cleaner, roles have just what they need, while users inherit most of their permissions only from @everyone.

One cool tip here, if your server is gated and requires each user to be verified by staff in some way (being given a role to access the rest of the channels), you can actually handle this at the Roles level. This gets rid of two channel overwrites you'd otherwise have on every single category, and also removes the little lock that would show up on every channel - rather than just on your staff ones. All you have to do is not enable View Channels for @everyone, enable it for your verification role, which hopefully has no other permissions, and then get rid of all those ugly channel overwrites.

Bonus tip, never give a bot more permissions than strictly what it needs to operate. A bot NEVER needs the Administrator permission and you probably shouldn't use bots that request it.

Channel overwrites

Speaking of channel overwrites, it's about time we went over them in detail. They show more complexity than roles by being tiered, and comparative on top of being additive (and... also subtractive). Let's go over what all of that means in practice.

An overwrite refers to a collection of permissions for a certain role or user; each permission can be denied, neutral, or allowed, and they allow us to create exceptions from our Role permissions. Let's go over what each of those states does by example.

Let's assume you have a server that doesn't allow embeds and media in their general channels, but you do have an art channel. Your @everyone role won't have Embed Links but you'd overwrite it to be enabled in the art channel. While we're here, also note how you don't have to touch anything else, all those other permissions default to neutral, which, as you might expect, does... nothing! It simply preserves the global role permissions.

Now, let's imagine your Mods role has the Manage Messages permission, but you don't want them to be able to delete messages in your staff channel. This is the perfect use case for a permission-denying overwrite.

Note my usage of the word "exception" earlier, if most of your channels require a specific overwrite, that's a rule, not an exception, and you should probably flip everything around.

Category overwrites & syncing

Catgories are groups of channels which can be assigned channel overwrites just like text & voice channels. When you set permissions on a category, channels within that category can be synced to those permissions, meaning that the permissions of those channels are the exact same as the category's permissions at all times. This is very useful for updating channels intended to have the same set of permissions, like a category of general chatting channels, or a category of announcement channels. Syncing permissions to categories is encouraged wherever possible for both this reason, and the ability to change all synced permissions with a few clicks, allowing channels to be quickly locked down in the case of a raid or similar.

Slash command permissions

Within the Integrations menu of your server settings, you can manage the permissions to use each slash command registered by each bot you have in your server. The permission hierarchy of Slash commands is slightly different. Denying a command or bot to a role or channel results in anyone with that role, or in that channel, not being able to use it, regardless of other channel or role permissions allowing it. This is with the exception of user permissions, which take priority over channel and role permissions. If you set a permission on a per-command basis, it will display as being "Not Synced" with the default permissions that are applied to all commands for the specified bot. Slash commands are useful for only allowing your moderation team to use moderation commands, allowing command use to be limited to certain channels, or only allowing potentially spammy commands to be used by trusted members. The integrations tab is being actively developed. The below UI and above permissions system could change at any point!

Security of least privilege

One of the scariest things that can happen in a server is someone abusing the permissions they have to damage or "nuke" the server. While there are "anti-nuke" bots like Wick that purport to keep your server safe by preventing this damage (Taking away critical permissions of enough dangerous actions are carried out), this solution can take away your moderators' ability to moderate in critical situations. This is where Security of least privilege comes in. By ensuring people only have the permissions they explicitly need, you lower the chances that someone will abuse their permissions, or get compromised by a malicious actor who will abuse their permissions. The Adminstrator permission is extremely dangerous to hand out, it should be entirely avoided if possible.

Closing thoughts

There's a lot to think about when setting up your community, but permissions are always the one thing people never have set up quite right. We hope this blog post has at least made your server's permissions easier to work with - don't worry if it's not quite perfect! While we heavily encourage taking the advice from this post, you can get by with imperfections here and there.