# Discord Community Management, Moderation and Automation > Discord server architecture, roles and permissions, moderation cover, onboarding gates and the bots we build. Verification, anti-raid, ticketing, logging. Page: https://synapsereality.io/services/growth/community-management/discord/ Last changed: 2026-09-23 ## Scope ### This covers Server architecture, roles and permissions, moderation cover, onboarding flow and the bots that automate all of it. ### This is not Telegram or forum communities, which have their own pages, or building a product feature, which is software development. ### Measured by Active members retained month over month. ## Overview A Discord server runs on grants. A role carries permissions for everyone holding it, and a channel overwrite adjusts them channel by channel. [Discord documents that Administrator bypasses channel overwrites](https://docs.discord.com/developers/topics/permissions). The second mechanical fact is speed. The room is synchronous, so a raid is finished in minutes and an unanswered question scrolls out of view the same evening. Server architecture and moderation cover are both answers to those two properties. This page is Discord only: server architecture, roles and permissions, moderation cover, onboarding and the bots underneath it. Telegram groups and Reddit threads have their own pages, linked above. Different mechanics, and a different tolerance for a brand in the room. The parent page owns strategy across the platforms at once. Shipping a feature inside your own product is software development and belongs on that page, not this one. ## A badly scoped role is an access-control bug, not untidiness That structure is an access control list with a chat client attached. People treat a role as a label. It is a security decision. The bypass is the sharpest edge. A member or an application holding Administrator reads your private staff channel no matter what that channel's settings say, because Administrator ignores channel overwrites entirely. Two grants get handed out casually and should not be. Manage Roles lets its holder change roles positioned below their own, so where a role sits in the list is part of your security model. Manage Webhooks lets its holder create an endpoint that posts into a channel under any name and avatar it likes. A webhook URL is a bearer token. Whoever has the string can post as it, from anywhere, forever. So the first artefact is a written permission map. Role, what it can do, and the job that justifies it. Servers accumulate a role per incident, and three years later nobody can say why the events role can see the finance channel. ## Onboarding decides who is standing in the room A gate that is too tight kills the growth you are paying for. A gate that is too loose is the raid surface. The one worth building costs a real person seconds, and costs an automated account more than the spam is worth. A rules agreement, a verification step tied to something scripts do not cheaply hold, then auto-role into the channels they actually came for. Write access is what the gate protects. Reading can be generous. It is posting, mentioning and linking that should be earned in the first minute. ## Cover, because Discord is synchronous and absence is visible On a forum, an unanswered question sits quietly until someone gets to it. On Discord it scrolls. A question asked at 21:00 with no reply by 21:10 tells the person who asked it that the server is dead. They are wrong, and they have already left. The gap between a five-minute response and a five-hour one is the gap between an inconvenience and a story people repeat. Cover is therefore a schedule with a written ladder: slowmode, timeout, kick, ban. Plus the short list of things a moderator escalates instead of deciding. Anything involving a real person's safety, a legal threat, and a security report about your product. That last one goes to engineering the same hour, and it does not sit in a mod queue. ## The bot is the part we build This is where doing the engineering and the growth in one team stops being a slogan. A server's automation should do six things. Gate verification, and assign roles on pass. Open a ticket as a private thread, and escalate that thread to a named human. Respond to a join spike by tightening the server without waiting for anyone. Log every moderation action somewhere you can query later. Discord's own audit log is a safety net, not a record you own. That is a few hundred lines. The alternative is four installed applications that each request broad scopes, because one install has to work for every server that adds it. Each one is a third party sitting inside your permission model, with its own hosting, its own token storage and its own future owner. We write the bot instead. The source goes in your repository and the token in your secret store, with the specific permissions its jobs require. ## Threads and forum channels are how support stops repeating itself A busy general channel is a queue that overwrites itself, and every answer given in it is given again next week. Moving questions into threads keeps the main channel readable. Moving them into forum channels, with titles, tags and a resolved state, makes the answers findable by the next person who has the same problem. There is a second output from that. The questions that keep recurring are a documentation backlog with the priorities already sorted. They belong in your docs, not in a moderator's muscle memory. ## The limits we keep on your server We do not buy members, run join-for-join swaps or seed conversations with accounts we control. An inflated member count breaks your only honest signal, which is how many people are still posting next month. We do not install an application we cannot read the source of and then grant it Administrator. If a tool you already use requires that, we will say so plainly and price the replacement. We do not keep the keys. The server stays in your ownership from the first day. At the end you hold the bot, the handbook and the permission map, whether you renew or not. The last one is a condition. If there is no product people want to talk about yet, a community cannot be staffed into existence. A server with paid cover and nothing to discuss is a quiet room with a salary attached. That is a thing to hear before the contract, not at the third monthly report. ## Who it is for A founder or head of growth whose users have already started talking in a server nobody was given the job of running. Permissions set up in one afternoon, moderators who are volunteers, and nobody awake when a raid starts. ## What you get - A written permission map covering every role, every channel overwrite, and the job that justifies each grant - The rebuilt channel and role structure, applied in your server, with the audit log showing every change - An onboarding and verification flow that gates write access behind a rules agreement and a check a scripted account fails - Moderation cover on an agreed schedule, with the response ladder and the escalation path written down before anyone needs them - The bot built for your server, source in your repository, token in your secret store, running on infrastructure you can point at - Anti-raid configuration covering verification level, join-rate trigger, slowmode defaults and the automated lockdown response - A weekly report of joins, leavers, posting members, moderation actions and the questions asked most often - A moderator handbook and a handover session, so your own people can run the server without us ## How it runs 1. Read the server before changing it. We go through every role, every channel overwrite and the audit log first. A role that can read a channel its holders were never meant to see is the finding that changes the whole plan. This pass is where it turns up, instead of in an argument later. 2. Rebuild the structure and the front door. Roles get rewritten to the least permission that does the job, channels get the overwrites that match, and onboarding gets a gate. A new member should reach the room they came for in under a minute while an automated account gives up before it can post. 3. Build the automation. We write the bot. The alternative is installing four of them. Verification, auto-role, ticketing, escalation, anti-raid and logging are a few hundred lines of code we can show you. That is a smaller attack surface than four third-party apps that each ask for administrator. 4. Run the cover and report what it found. Moderators work an agreed schedule with a written ladder for slowmode, timeout, kick and ban. There is a named escalation path for anything involving a real person's safety, and for a security report about your product. The repeated questions go into a weekly report because they are a documentation backlog. 5. Hand it over. The handbook, the bot source, the permission map and the moderator training are yours at the end. An arrangement where the agency is the only party who knows why a role exists is not a service, it is a dependency. ## Questions ### Can you moderate the server we already have, without rebuilding it? Yes, and we often start there. But the audit comes first. Moderation cover on a server with a badly scoped role is guarding the door of a building with an open window. If we find a role or a bot that can read channels it should not, you get that in writing on day one. You decide whether to fix it now or later. ### Why build a bot instead of installing one that already exists? Because of what installing costs in permissions. A bot is a third party inside your access control list. The popular ones ask for broad scopes because one install has to work for every server that adds it. The jobs that actually have to get done are a verification gate, auto-role, tickets and raid response. That is a small amount of code. We write and host it instead of granting a stranger's application the ability to read every private channel you have. ### Is it ever fine to give a bot the Administrator permission? Almost never, and the reason is mechanical. Administrator bypasses every channel overwrite in the server, so a bot holding it reads your private staff channels regardless of what those channels say. You also inherit that bot's security. Its hosting, its token storage, the account of whoever owns it, and whoever buys the project in two years. If its token leaks, your server leaks with it. We grant each integration the specific permissions its job needs and write down why. ### What actually happens during a raid? Raids are fast, which is what makes Discord different from a forum. The bot watches join rate and account age. When a spike trips the threshold it raises the verification level, turns on slowmode and restricts posting for new joins until a human confirms. That buys the time a person needs to arrive. Afterwards we clean scrollback, ban the accounts, and tell you what the gate let through so the threshold can be tuned. ### Do you cover the server around the clock? Cover is whatever schedule we agree and put into the contract. We sell honest hours, and we will not sell you an implied always. Outside those hours the automation holds the line. Raid response, slowmode, ticket capture. A named person on your side gets paged for the short list of things a bot must not decide alone. ### Who owns the bot, the data and the server at the end? You do, throughout. The source lives in your repository, the token in your secret store, the application under an account you control. The server is never transferred to us. Ending the engagement means we hand over the handbook and leave. Nothing we build needs us to keep running. ### Our members are developers and they hate being marketed to. How do you post? Under our own named accounts, with a role that identifies us as staff. We do not pose as organic members. Discord reads as a room, and press-release voice is noticed immediately in a room. We write like people who know the product. We do not use @everyone for anything that is not genuinely everyone's problem. When something is broken we say so, and do not route it through a macro. ## Related services - [Community Management](https://synapsereality.io/services/growth/community-management/) - [Telegram Community Management](https://synapsereality.io/services/growth/community-management/telegram/) - [Reddit and Forums](https://synapsereality.io/services/growth/community-management/reddit/)