# Set up role-based access > A careful, step-by-step guide to delegating Aethor features to Discord roles This guide is for the person who manages the server. It assumes Aethor is already in the server and you can open **Settings → Permissions** in the dashboard. If the page is read-only, start with [Why the permission page is read-only](/docs/permissions/troubleshooting#the-page-is-read-only). ## Before changing anything Write down the job you want to delegate in one sentence. Good examples are: - "The suggestion team may review and resolve suggestions, but may not change suggestion setup." - "The support team may configure tickets, but may not publish button roles." - "Community helpers may add and update tags, but may not delete them." Avoid a sentence like "Make this role an Aethor admin." It is too broad to tell whether the result is safe. Create the Discord role first and assign it to one test member. The role does not need broad Discord permissions just to satisfy an Aethor role rule. ## 1. Pick the smallest useful group Open **Rules** and find the feature. The level after the dot tells you roughly how powerful the group is: - **Members** covers ordinary participation and read actions. - **Moderators** covers daily content and community decisions. - **Managers** covers configuration and publishing. For the first example above, edit **Suggestions · Moderators**. Do not edit **Suggestions · Managers**, because that group controls the suggestion setup itself. Expand the group before editing. Read the action list and the **Commands affected by this rule** box. If one action should have a different audience, you can add an action override after setting the group. ## 2. Choose the rule Select **Edit** on the group. The editor offers two choices for a group: - **Use Discord permissions** removes the custom group rule and returns to Aethor's default. - **Only selected roles** replaces the default actor requirement with the roles you select. ![The permission rule editor comparing the current audience with a selected-role rule](../../../../../static/screenshots/dashboard/permission-rule-editor.png) Select one or more roles. A member only needs one selected role to satisfy the rule. Multiple role rules are therefore **OR**, not **AND**: selecting `@Suggestion Team` and `@Senior Staff` means either role qualifies. Leaving the selected-role list empty means **nobody except the server owner and Discord administrators** qualifies through the group. This is useful for deliberately closing a feature, but the editor warns because it is easy to do accidentally. Select **Apply change**. This only adds the change to your draft; it is not live yet. > [!NOTE] > The pending bar is the boundary between editing and publishing. Nothing changes in Discord until you review the batch and select **Save all changes**. ## 3. Add an action override only when necessary Expand the group and choose **Edit** beside one action. An action has a third choice: - **Follow [group name]** removes the action's exception and follows the group again. Use an override when the group is almost right. For example: - give `@Suggestion Team` the **Suggestions · Moderators** group; - set **Export suggestions to CSV** to `@Senior Staff` because exports contain more data; - set **Delete suggestions** back to **Use Discord permissions** if deletion should stay with members who have **Manage Messages**. An override always wins over its group. It does not matter whether the override was saved before or after the group rule. ## 4. Review the pending changes The bar at the bottom counts pending changes. Select **Review changes**. Aethor validates the entire batch and shows the current audience beside the proposed audience, including roles that gain or lose access. **Save all changes** applies the validated batch together. If one change is invalid, none of the changes is applied. If another administrator changes the rules while your editor is open, Aethor reports a version conflict. Your draft stays visible, but you must reload the latest rules before saving. Reloading discards that local draft, so copy down any complicated choices first. ## 5. Test the result as a role Open **Access**, choose **Role**, select the role you changed, then select **Check all access**. The role-only check models a member who holds `@everyone` and that one role. This makes it ideal for checking what the role itself grants. It cannot include other roles, ownership of a suggestion, or a particular member's current Discord permissions. Review both views. **Commands** groups results by slash command. Discord visibility applies to one top-level command, even when its subcommands use different capabilities. **Capabilities** shows each action as **Allowed**, **Denied** or **Conditional**, including required roles and missing bot permissions. ## 6. Test the real person Still under **Access**, switch to **Person**, find the test member and run **Check all access** again. This uses their current server membership, all current roles and Discord permissions. The person check is the final answer for the member's present state. It can differ from the role-only check because the person may: - hold another selected role; - have **Administrator**; - own the suggestion being edited or deleted; - have Discord permissions used by an action that still follows the default. After changing roles in Discord, use **Refresh permissions** at the top of the dashboard before treating an old result as current. ## 7. Keep slash-command visibility in sync Aethor can allow a role at runtime while Discord still hides the command from that role. Enable **Sync command visibility with Discord** when you use custom role rules. The sync mirrors role access into Discord's command picker; Aethor remains the authority when the action runs. Read [Discord command visibility](/docs/permissions/command-visibility) before enabling it. The person authorizing sync needs enough Discord authority and must outrank the roles being mirrored. ## Examples ### Suggestion moderators without Manage Messages Set **Suggestions · Moderators** to `@Suggestion Team`. Keep **Suggestions · Managers** on Discord permissions. Test state changes, duplicate marking, review actions and blacklist actions. Then enable command visibility sync. ### Ticket managers only Set **Tickets · Managers** to `@Support Leads`. Do not also grant **Button roles · Managers** or **Thread support · Managers** unless that is part of their job. Confirm Aethor can manage channels where tickets are created. ### Tag editors who cannot delete Set **Tags · Moderators** to `@Content Team`, then override **Delete server tags** to `@Senior Staff`. The other tag actions continue following the group. ### Read-only helpers Prefer granting only the relevant read action as an override instead of an entire moderator or manager group. For example, override **View suggestions** or **View autoresponders** for the helper role and leave mutation actions unchanged. ## Undo a rule To restore a group, edit it and choose **Use Discord permissions**, then review and save. This removes the stored group rule. To remove an action override, edit the action and choose **Follow [group name]**, then review and save. Do not choose **Use Discord permissions** unless you intentionally want that action to ignore the group's selected roles and return to its built-in Discord gate. After a rollback, run both a role check and a person check. If command visibility sync is enabled, wait for the status to return to **Synced** or use **Sync now** if the dashboard reports drift.