Permission reference

The tables Bloom’s permission checks are built from: the Discord permissions it recognizes, the names you type when granting a fake permission, and the permission each dashboard module requires. For how these checks combine in practice, see Permissions and hierarchy.

​

Fake permissions

When you grant a fake permission with !fp grant, Bloom accepts either the grant name or one of its aliases, then treats the member or role as if it had the matching Discord permission for Bloom commands only. A fake permission never grants a real Discord right. The names below are grouped the way !fp perms shows them.

​

Administrative

​

Moderation

​

Channels and threads

​

Messages

​

Members and roles

​

Expressions and events

​

Voice and stage

​

Apps and insights

​

How Bloom resolves a permission

For a command that needs a permission, Bloom allows the member if any of these holds, checked in order: Bloom checks its own bot permission for the action separately, in the same channel. See the guide for how these two checks differ.

​

Dashboard module access

Opening a server’s dashboard requires that you are an administrator, the server owner, or hold a dashboard access role configured for that server. Once inside, each module is visible only to members who hold the permission below. Administrators and the owner see everything. For the login flow and how a dashboard access role is granted, see Dashboard access.

​

Hierarchy checklist

Permissions decide what is allowed; role position decides what is possible. Before relying on Bloom to manage roles or members, confirm:

• Bloom’s own role sits above the roles of members you moderate.
• Bloom’s role sits above every role it assigns: level rewards, autoroles, and the mute and jail roles.
• A moderator’s highest role is above the members they need to action, since Discord blocks actions against anyone ranked higher.
• The @everyone role and managed roles (bot or integration roles) cannot receive fake permissions.

​

Related pages