# Permissions and capabilities
> Decide exactly which Discord roles may use each part of Aethor
Aethor's permission system asks who may perform a specific action. It does not give someone a vague "staff" switch. You can let a support role manage tickets without letting it change suggestions, or let a suggestion team resolve ideas without giving it Discord's broad **Manage Messages** permission.
You manage these rules in the dashboard. Pick a server, then open **Settings → Permissions**.
## Start here
Keep these four rules in mind:
1. A **capability** is one action, such as "change a suggestion's state" or "publish button roles".
2. A **group rule** controls a useful bundle of related actions. Most servers only need group rules.
3. An **action override** changes one capability without changing the rest of its group.
4. A role rule **replaces** the normal Discord permission requirement. It is not added on top of it.
That last point matters. Suppose **Suggestions · Moderators** normally requires **Manage Messages**. If you change the group to **Only selected roles → @Suggestion Team**, then:
- a member of `@Suggestion Team` can use those actions without **Manage Messages**;
- someone with **Manage Messages** but without `@Suggestion Team` no longer qualifies through that permission;
- the server owner and Discord administrators still retain access;
- Aethor's own Discord permissions and premium requirements still apply.
## The permission screen
The **Rules** tab is where you decide who gets access. Features are divided into 15 groups, such as **Suggestions · Members**, **Suggestions · Moderators**, **Tickets · Managers**, **Autoresponders · Moderators** and **Anti-invite · Moderators**.
Each group shows its current audience, how many actions it contains, the slash commands it affects, and whether any action has its own override. Expand a group to inspect every capability before changing it.
The **Access** tab answers the opposite question: **what can this person or role actually do?** It checks the same server-side rules used by the dashboard, slash commands, buttons, menus and modals.
## Which guide do you need?
## What the three default levels mean
When a group says **Discord permissions**, it uses the following built-in rule:
| Level | Who qualifies by default |
| --- | --- |
| **Members** | Any current member of the server. |
| **Moderators** | Members with Discord's **Manage Messages** permission. The soft-ban capability is a deliberate exception and requires **Ban Members**. |
| **Managers** | Members who have **Manage Channels**, **Manage Messages** and **Manage Server**. All three are required. |
These labels describe Aethor's defaults; they do not create or edit Discord roles.
## Checks that a role rule never bypasses
A role grant only replaces the actor's normal Discord permission test. It cannot make an impossible action possible. Aethor still checks:
- that the person is currently a member of the server;
- that Aethor itself has the Discord permissions needed to perform the action;
- that the server has premium when the action is premium-only;
- that the server, role and target still exist;
- that current Discord data is available;
- ownership and hierarchy rules that belong to the action itself.
For example, granting **Button roles · Managers** to a team does not let Aethor assign a role above Aethor's highest role. Granting **Anti-invite · Managers** does not unlock Anti-invite on a free server.
## Access that cannot be delegated away
The server owner and members with Discord's **Administrator** permission always keep actor access. This is the recovery path if a rule is too restrictive.
The ability to view and change the permission system itself is stricter: `guild.permissions.read` and `guild.permissions.update` always use the manager rule, which requires **Manage Channels**, **Manage Messages** and **Manage Server**. They cannot be placed behind a custom role rule. Aethor ignores any stored override that tries to change those two capabilities.
Suggestion authors also keep two narrow owner actions: editing their own suggestion and deleting their own suggestion. A **Suggestions · Moderators** role rule controls staff use of those actions; it does not take those author actions away.
## Rules apply everywhere
The same capability check protects:
- dashboard pages and API requests;
- Discord slash commands;
- buttons, select menus and modal submissions;
- suggestion and configuration actions that continue after the first click.
Discord still decides whether a slash command is visible in its command picker. That is a separate presentation layer, which is why role-based servers should read [Discord command visibility](/docs/permissions/command-visibility) and usually enable the sync.