Roles & permissions
Give each role the access it needs, then test it.
Two separate checks
Discord controls what an app can do in a server and channel. Watchpost will also need its own rules for who may use sensitive features. The second layer is a development requirement, not a confirmed implementation.
A role can have a server-level permission while a channel override changes its effective access. Review both when an action works in one channel but fails in another.
Proposed access model
| Responsibility | Suggested access |
|---|---|
| Connection and settings | Owner or explicitly trusted administrator |
| Moderation actions | Authorized moderators |
| Case corrections | Staff leads |
| Session management | Designated hosts |
| Public status | Members, if enabled by the owner |
Role position matters
Discord limits which roles a bot can manage based on its highest role. If a released feature needs role management, place the bot above the roles it must manage and give it only the permissions that feature needs. Avoid granting Administrator as a routine fix.
Check access after changes
Test with an authorized staff account and an ordinary member. A hidden command is not a substitute for a permission check when the command runs. Record unexpected access as a bug and pause use of the affected feature.
Reference: Discord permissions documentation ↗