Roll out Aleeva on a large community server

On a small server you can invite Aleeva and let people discover her as they go. On a server with thousands of members that is rarely what you want, because once she joins, every member can use her commands straight away.

This guide turns that around. You invite Aleeva with almost no permissions, close every command before anyone finds them, and then grant access back one deliberate step at a time. She starts out able to see your server and do nothing else, and every capability she gains after that is one you chose, for a feature you asked for.

Bringing a big community over? Talk to us first

You do not have to do this alone. If you are planning an Aleeva rollout for a large community, tell us what you are trying to achieve on the support server and the team will go through the setup with you: which permissions to grant when, which features are worth switching on first, and how to fit Aleeva around the moderation tooling you already run.

We do this regularly for bigger servers, and it is much easier to plan the rollout with you up front than to untangle it afterwards.

Who needs to do this

Steps 1, 2, 3 and 7 happen in Discord's own server settings, so they need the server owner or a member with Discord's Administrator permission. Steps 4, 5 and 6 happen in , which runs in a direct message with Aleeva.

Invite Aleeva with as few permissions as possible

Invite Aleeva to your server

The invite link arrives with every permission Aleeva can use already ticked. On a large server, untick them. Leave View Channels and nothing else, then authorise.

This is the opposite of Quick start, and deliberately so. A small server is better off with Aleeva working the minute she arrives. A large one is better off with her arriving inert, so that every capability she has is one you granted on purpose, on a date you remember, for a feature you asked for.

You are not locking yourself out of anything. Permissions go back onto the Aleeva role in Server Settings, Roles, one at a time as you switch features on, and Discord permissions tells you which permission each feature needs.

A missing permission fails quietly

This trade is the whole point of the guide, but it does bite. A feature whose permission is missing does not announce itself, it just does not work. When something you enabled later on seems dead, check the Aleeva role's permissions before you check anything else.

Two things follow from arriving with only View Channels, and both are expected:

• You will not see the welcome message Aleeva normally posts in your default channel, because posting needs Send Messages.
• Scam Protection is on by default and is already watching, but it cannot remove anything yet. Step 4 covers what it can and cannot do until you grant it what it needs.

Close every command before anyone finds them

Do this immediately after the invite, before you announce anything.

Click your server name and choose Server Settings, then open Integrations and click Aleeva. The Command Permissions section restricts usage of the application's commands to roles, users and channels. It has three boxes, and for now you only need the first two:

• Under ROLES & MEMBERS, set @everyone to the red ✗.
• Under CHANNELS, set All channels to the red ✗.

Your members can no longer invoke any Aleeva command anywhere. You will grant access back deliberately in step 7.

This covers commands, not features

Command Permissions govern slash commands and right-click app actions. They do not govern what Aleeva does on her own, such as greeting members who join or watching for scams. That behaviour comes from features, which you enable in and which stay off until you do, so enable them one at a time and only after the permissions around them are in place.

Scam Protection is the exception: it is on by default and is already running. Step 4 is about tuning it, not starting it.

Give Aleeva access only in the channels you want

After step 1 the Aleeva role holds one thing: View Channels, server wide. So the question here is narrower than it looks. It is not what she may do, it is what she may see.

Aleeva has her own role in your server, created when she joined, so you scope her the same way you scope any role: through channel and category permissions. Work top down, denying View Channel for the Aleeva role on the categories she has no business in, such as your staff and archive areas. Leave it on everywhere she should watch or eventually serve.

Everything beyond seeing arrives later. Send Messages and the rest go onto her role feature by feature in the steps below, and both Send Messages and Read Messages are designed to be declined per channel, so narrowing her afterwards is a supported way to run her rather than a workaround.

Keep in mind which features will eventually need to work where. Event Management creates channels and reads history, and Scam Protection has to see messages to catch them, so a category you hide from her now is a category those features cannot serve later. Discord permissions maps every permission to the features that depend on it.

Scam Protection only covers channels Aleeva can see

Aleeva checks messages by reading them. If the Aleeva role cannot see a channel, she never sees what is posted there, so Scam Protection does not cover it. That gap is silent: nothing warns you, the channel simply goes unwatched.

So deny View Channel per channel rather than by habit. Every channel where members can post links or images is one worth leaving her able to read, and busy public channels are exactly where scams land. Watching costs you nothing visible, because seeing a channel and speaking in it are separate permissions: leave View Channel on and simply never grant Send Messages there.

Configure Scam Protection, which is already running

Every other feature waits for you. This one does not: Scam Protection is on by default, so from the moment Aleeva joined she has been checking new messages against a blocklist of known phishing domains and a set of known scam images.

After a minimal invite she can watch but not act. Detection needs only View Channels, which she has, so she already sees the scams. Removing the message needs Manage Messages, and the stronger actions need their own permissions: Kick Members to kick, Ban Members to ban. Until you grant those on the Aleeva role, Scam Protection is a smoke detector with no alarm attached.

So this step is a real decision rather than a formality. Grant Manage Messages if you want her deleting scam messages, and add Kick Members or Ban Members only if you want her handling the sender too.

The default behaviour is deliberately gentle. Out of the box she removes a detected scam message and takes no action against the sender, so nothing disruptive happens before you have made a decision. Open and choose Scam Protection to set the message and user actions, the occurrence threshold, a notification channel, and the image-related options. Her alerts need Send Messages in whichever channel you pick. Scam Protection explains each option, including the instant timeout on scam images and the cross-server network timeouts.

If you already run other moderation bots

Large communities usually have an anti-phishing or automod bot already, and two systems watching the same channels will both act on the same message. Before you widen Aleeva's channel access, decide who owns what:

• Pick one system to punish. Leaving Aleeva's user action at its default, and simply not granting her Kick Members or Ban Members, means she removes the scam message and lets your existing bot handle the sanction. If you would rather Aleeva did the sanctioning, grant her those permissions and turn the other bot's punishment off instead. What you want to avoid is both acting, which lands two timeouts or a timeout on top of a ban for a single message.
• Expect the deletion race. Whichever bot gets there first removes the message and the other finds nothing. That is harmless, but it does mean your mod log will show gaps, so do not read a missing entry as a missed detection.
• Send her alerts somewhere you already look. Point Aleeva's notification channel at your existing mod-log channel, or a dedicated one next to it. The alert says whether a scam link or a scam image triggered it, which is what tells you which system caught what.
• Keep other bots off her radar. If another bot quotes or relays message content, it can repost a scam link itself and trip Aleeva. Put those bot accounts on Aleeva's ignore list so she skips them.

Set Aleeva's own permissions, starting with the administrators

Now open . It arrives as a direct message and can be opened by the server owner, anyone with Discord's Administrator permission, and any member holding the Aleeva Administrator permission.

Go to the Permissions category and assign Aleeva Administrator to your server administrators, and to nobody else. It is the key to this entire configuration: anyone holding it can open , change any feature, and undo every boundary you are setting up here. Treat it exactly as you treat Discord's own Administrator permission.

With your administrators in place, turn on the features your community actually asked for, one at a time. For each one, look up what it needs in Discord permissions, grant that permission on the Aleeva role, and confirm she can see the channels it has to work in. Enabling a feature and granting its permission are two separate acts, and after a minimal invite the second is the one people forget.

Hand out event permissions sparingly

Event permissions live in the same Permissions category, and they deserve their own decision because they let members create things rather than just read them.

• Aleeva Events Leader lets a member manage events. On a large server this is the permission that quietly turns into noise, because every holder can put events on your calendar. Give it to the people who genuinely run your raids, strikes or guild missions, not to a broad member role.
• Aleeva Events Admin is the wider of the two. It also opens the settings behind , which define how events behave for everyone on the server. Keep this close to your administrators.

If nobody holds an event-leader permission yet, Aleeva offers to make the creator of a new event its leader, so you can start narrow and widen later. See Event Management for what these permissions unlock.

Open up the commands you actually want

Go back to Server Settings, Integrations, Aleeva. Everything is still denied from step 2, so from here you are granting, not restricting, which is a much easier state to reason about.

The third box on that screen lists every command individually. For each command your community should have, add a Role & Member Override for the roles that may use it, and limit it to the channels where it belongs. A useful pattern on a large server is to allow the general Guild Wars 2 lookup commands in your bot or lounge channels, and leave the moderation-facing ones restricted to staff roles.

Restrict who can use /check-user and /check-account walks through that screen step by step with screenshots, including how to see what a command defaults to before you override it.

Before you announce it

Run through this list with a member account that holds no special roles:

• Aleeva's commands do not appear in channels you did not open up.
• The commands you did open appear only in the intended channels.
• is unavailable to ordinary members.
• Only the roles you chose can create events.
• The Aleeva role holds a permission for every feature you switched on, and none you did not.
• Aleeva can post in every channel where you enabled a feature that needs to reach members.
• Aleeva can see every channel where members post links or images, so Scam Protection actually covers them.
• Scam Protection's action does not double up with whatever your other moderation bots already do.

If something is missing, it is far more likely to be channel access from step 3 than a command override from step 7, so check that first.