Permission model
See how Root works out what a member can do, so your roles behave the way you expect.
Before you start building roles, it helps to know the model underneath them. Root decides permissions a little differently from what you might be used to, and a few minutes here will save you a lot of head scratching later. If you'd rather jump straight to definitions, start with the Roles and permissions overview.
Roles don't rank
You might expect roles to work like a ladder, where a member's highest role wins and outranks the ones below it. Root doesn't work that way.
Roles are flat. None sits above another, and a member's abilities are the combination of every role they hold, not whichever one is on top. A member with a Moderator role and a Member role has everything either role grants, full stop.
You can still order your roles in the list, and every member has a primary role that sets their name color. That ordering is purely about how things look. It never changes what a member can do.
Reordering your roles or changing someone's primary role is always safe. It only affects display color and sorting, never permissions, so you can tidy your roles list without worrying about breaking access.
Permissions add up
Root grants a permission if any of a member's roles allows it. Give someone a second role and you can only ever give them more, never less.
This means you build up what a member can do by handing out roles, not by ranking them. There's no way to cancel a permission by adding a role on top. The only thing that takes a permission away is setting it to Deny for a specific channel, covered in Manage channel visibility.
One catch when you assign roles: you can only grant permissions you have yourself. Any permission you don't hold appears grayed out while you're editing a role.
Two separate questions
Every channel comes down to two separate questions, and it's easy to mix them up:
| Question | Decided by |
|---|---|
| Can the member see the channel? | Channel Visibility |
| Can the member do the action? | The permissions from their roles |
Channel Visibility controls who can see a channel: if a member isn't in it, the channel is invisible, no matter how many permissions they have. The role permissions then decide what they can do once they're in.
Because these are separate, a member can hold the Send Messages permission and still not see a channel, simply because they're not in that channel's Channel Visibility. When something doesn't behave as you expect, it's almost always one of these two questions, not both. Permission troubleshooting walks through how to tell which.
The one true override
One permission ignores everything above. A role with Community Full Control grants every ability everywhere and bypasses Channel Visibility and every permission setting. It's the single real exception to the whole model, which is exactly why you should grant it sparingly.