Troubleshooting
Removed Moderator Role but Discord Access Still Works
The role is gone, but older permissions or a second role can keep access alive.
Is this your situation?
You removed the moderator role, but the former moderator can still act as if they have it. You expected the access to end, but it is still working.
The short answer
You expect the access to be gone, and instead it keeps working. Channel permissions start with server permissions as a base. Check the member's remaining roles and any channel-specific permissions before assuming the role removal did not work.
What you see, and why
| Symptom | Cause |
|---|---|
| You still see the former moderator able to view or post in channels. | An individual's server-wide permissions come from adding up all allows for every assigned role, plus @everyone. |
| You find access works in one channel but not another. | Channel permissions start with server permissions as a base. |
| You notice a specific deny you expected does not apply. | Allows for a specific member are applied last, if they exist. |
| You feel the member bypasses the removal entirely. | Denies for a specific member are applied, if they exist, after the role-level allows. |
Check these first
- Check remaining roles Confirm no other role still grants moderator-level permissions.Verify: Open the member's profile and review every role still assigned.
- Check channel-level overrides Channel permissions start with server permissions as a base.Verify: Open the channel's Permissions tab and look for the member or their roles listed.
- Check for a member-specific allow Allows for a specific member are applied last if they exist.Verify: Look in channel Permissions for the member's name added individually.
How Discord handles this
- An individual's server-wide permissions are determined by adding up all allows for every role assigned to them, plus @everyone.
- Channel permissions start with server permissions as a base.
- All the denies of a member's roles are summed up and applied at once after the @everyone allows.
- Allows set for a specific member are applied last, if they exist.
Which path applies to you?
- Does the member still have another role with moderator permissions? Server-wide permissions add up all allows from every assigned role plus @everyone.
- Does the channel have a separate permission setting for this member? Channel permissions start with server permissions as a base.
- Is there an individual allow set for this specific member on the channel? A member-specific allow is applied last, if it exists.
- Do the member's roles carry a deny that should block the channel? All the denies of a member's roles are summed up and applied at once after the @everyone allows.
Step by step: finding the cause
- Open the member's profile Check which roles remain assigned after the moderator role was removed.Confirm: Check the Roles list for any role beyond @everyone.
- List remaining roles Server-wide permissions come from adding up allows for every assigned role plus @everyone.Confirm: Check each remaining role's permissions individually.
- Open the affected channel's Permissions tab Channel permissions start with server permissions as a base.Confirm: Check whether the member or their roles appear in the channel permission list.
- Look for a member-level entry A member-specific allow is applied last, if it exists.Confirm: Check for the member's name listed individually under channel permissions.
- Check role-level denies and allows Denies for a member's roles are summed and applied together after @everyone allows.Confirm: Check the Denied and Allowed columns for each role.
- Remove or adjust the remaining source of access Remove the extra role or the member-level allow once it is identified.Confirm: Check the Permissions tab again to see the access no longer listed.
Common mistakes
- Assuming one role removal clears all access Server-wide permissions add up allows from every role still assigned, plus @everyone.Why it happens: You check the removed role and overlook that another assigned role grants the same access.
- Overlooking channel-level settings Channel permissions start with server permissions as a base.Why it happens: Channel-specific permissions were set separately and never reviewed.
- Missing a member-specific allow An allow set for a specific member is applied last, if it exists.Why it happens: A direct member allow was added earlier and forgotten.
- Ignoring the order role denies apply in All the denies of a member's roles are summed up and applied at once after the @everyone allows.Why it happens: Another role's allow was not checked alongside the removed role's deny.
Quick reference
| Situation | What to check |
|---|---|
| Access persists after role removal | Other assigned roles, since allows from every role add up. |
| Access differs by channel | Channel permissions, which start from server permissions as a base. |
| A specific deny does not apply | Member-specific allows, applied last in the hierarchy. |
| Order of permission application | Role denies are summed and applied at once after @everyone allows. |
| Member-level denies apply after role allows | Denies for a specific member are applied, if they exist, after the role-level allows. |
| Where to review channel-specific behavior | Review the channel permission hierarchy for this server. |
Keeping track of who has access
Delvia keeps a record of every role and channel permission tied to a person, so the access you diagnosed here is easier to find next time.
Was this helpful?