> For the complete documentation index, see [llms.txt](https://docs.exoguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.exoguard.io/tutorials/permissions.md). # Permissions Here is a list of commands with their default permissions: * `Get enrollment information`: everyone (this is a user command, not a slash command) * `/config`: administrator * `/delete`: administrator * `/enroll`: everyone * `/info`: everyone * `/login`: everyone * `/logout`: administrator * `/subscription`: administrator To configure permissions for the integration, go to Server Settings -> Integrations -> Exoguard:

Screenshot of the Server Settings page, in the Integrations category with Exoguard selected.

## Recommendations Here is a list of recommendations regarding Exoguard command permissions: * Keep `/info` public but restrict it to your commands channel to avoid clutter * Restrict `Get enrollment information` if you want to have hidden staff members * Restrict `/enroll` to reduce spam in your audit channel if your [audit webhook](/tutorials/audit-webhook-setup.md#setting-the-audit-webhook) is configured * Keep `/subscription` restricted, you can be held responsible for the use of stolen vouchers * Only [allow assigned roles](#allow-users-with-assigned-roles-to-use-the-logout-command) to `/logout` to avoid cluttering your members' slash commands list * Separate vanity roles (hoist, color, ping) and permission roles, then only assign permission roles *** ## Separate vanity roles and permission roles Here is an example of separate vanity roles and permission roles:

Screenshot of 4 roles in Server Settings: 2 vanity roles and 2 permission roles.

{% hint style="warning" %} Make sure your vanity roles are **above** your permission roles to maintain hierarchy!\ If you put a permission role above, logged in users can act against logged out users. You can also have a `Staff` role above all to make all your staff hierarchically equal. {% endhint %} Having vanity roles allows your members to know at all time who is part of your staff and who isn't, which will avoid confusion in your community. These are the roles that should have a color and be hoisted, but not hold any permission as they are not assigned and therefore permanent. Permission roles must be assigned, otherwise there is honestly not much point in using Exoguard for your community. You can make them mentionable instead of the vanity roles if you want to have an "on-call" or "active" staff system, where only logged in staff members will be notified. *** ## Allow users with assigned roles to use the `/logout` command While users can always log out by using the big red `Log out` button on their login confirmation message, you will certainly want to allow assigned roles to use the [/logout](/commands.md#logout) command as well. To do that, click on the [/logout](/commands.md#logout) command within the Exoguard integration settings:

Screenshot of the /logout permissions override modal, with the Moderator Perms role allowed.

This command is restricted by default since it is completely useless for logged out users.\ You can safely allow everyone to use it, this would however clutter their slash commands. *** ## Restrict all public commands to make them staff-only {% hint style="info" %} This is not mandatory at all, restricting public commands is only a matter of preference. {% endhint %} While public commands (aka commands everyone can use) are not dangerous, you may want to prevent your server members from executing them on your server if they aren't part of your staff. We recommend creating a role without any server permission that you will give to your staff.\ In this example, it will be named `Staff` but you are obviously free to use whatever name you want. Once your role is created, set a global override to deny everyone and allow `Staff` in the settings:

Screenshot of a global override, the Staff role can run commands and everyone else cannot.

{% hint style="info" %} This doesn't give access to admin-only commands unless you override them individually.\ Using this option will only restrict commands, not give more access, it is completely safe. {% endhint %} Once you have restricted all public commands, you can still allow individual commands afterward.\ As part of our [recommendations](#recommendations), you could allow `/info` for everyone in your commands channel.