XenForo permissions look like a spreadsheet until they bite. A new admin usually copies another site’s groups, grants “Admin” to a trusted friend, and only later notices that Registered users can see a staff forum or that guests can no longer read anything. This guide is a starter map: groups first, then nodes, then the three mistakes that create those tickets.
You do not need every checkbox documented. You need a model you can explain to the next moderator you hire.
The model: groups plus analysis
XenForo does not treat a user as a single role. A member belongs to a primary group (almost always Registered) and zero or more secondary groups (Moderator, VIP, Donor, Staff). Each permission is then analysed across those groups:
- Yes wins over No
- Never wins over everything
- Not set means “do not vote”
That last one is the whole game. If you set No on Registered for “View node” and Yes on VIP, a VIP who is also Registered still sees Yes. If you set Never on Registered, VIP cannot save them.
Use Never as a lock (banned, unconfirmed, “this group must not post”), not as everyday denial. Everyday denial is Not set on the broad group plus Yes on the narrow one.
Start with four groups
Ignore the dozen groups you saw on someone else’s screenshot. A new board needs four:
| Group | Primary? | Job |
|---|---|---|
| Unregistered / unconfirmed | system | Guests and people who have not clicked the mail link |
| Registered | yes, for members | The default human |
| Moderator | secondary | People who handle queues, not the whole ACP |
| Administrative | secondary | ACP + dangerous tools |
Promote people by adding a secondary group, not by changing their primary group away from Registered. Changing primary group is how you accidentally strip “can view” from a super moderator because Registered was carrying the view permission.
Create extra groups later (Supporters, Alumni, Team) only when you have a permission that those people should have and Registered should not.
Node permissions are not user permissions
Global permissions say what a group can do in principle. Node permissions say what they can do in this forum.
A typical public board:
- Root category: Registered = View, Post; Guests = View only
- Staff forum: Registered = Revoke view; Moderator / Administrative = View + Post
- Private client forum: Registered = Revoke; a dedicated “Client” secondary group = View + Post
Revoke on the node is the correct tool when Registered should exist as a group but must not see this forum. Do not create a second “Registered but secret” primary group to fake privacy.
Check the permission analysis page for a test user after every change. If analysis still says Yes on “View” for a Registered account, the staff forum is public. Fix that before you write anything in it.
Three mistakes that create lockouts
1. Never on Registered for a core action. You meant “members should not start threads in Announcements”. You set Never globally. Now nobody, including you in a second browser, can start threads anywhere. Restrict the node, not the species.
2. Staff as primary group. The admin account’s primary group becomes Administrative. Registered is no longer applied. A later change to Administrative “to tidy the ACP” removes View. You have an admin who cannot see the front end. Keep Administrative secondary.
3. Copying a live board’s groups into a fresh install. You import names without importing the analysis. “VIP” on the other site was Yes-on-top-of-Registered; on yours it is an empty group with Not set everywhere. People pay, nothing changes, they write in the ticket queue. Build groups from this board’s needs, then name them.
A first-afternoon checklist
- Create a throwaway Registered account and a throwaway guest session. Use them after every change.
- Confirm guests can read the public forums you actually want public — and nothing else.
- Confirm Registered can post in the general forum and cannot see Staff.
- Confirm a Moderator secondary group can see Staff and the approval queue, and cannot open ACP options, add-ons, or user deletion.
- Confirm your own account still uses Registered as primary.
- Write the group list down in a staff thread. The next admin will not remember why “Donors” exists.
Permissions are finished when a stranger can use the board and a staff member cannot accidentally de-staff themselves. Everything after that is decoration.