Managing XenForo user groups and permissions at scale

The four default groups will run a new board. They will not run a board with a Verified ladder, a paid lounge, three cosmetic ranks, a Restricted discipline group, and eighty nodes. At that point the failure mode is not “I do not know what Yes means.” It is a promotion that only touches people who logged in this week, a Never you cannot see without Analyze, a private node that still inherits Post, and a user-level override someone applied in 2024 and forgot.

This is not the starter permissions map. That article is the first afternoon: four groups, Registered stays primary, Revoke on a staff forum, do not Never the species. Read it if you have not. This article assumes that model and goes to the official scale tools: Groups & permissions → Analyze permissions, the official Staff room private-node walkthrough, User group promotions (hourly, recently-active only), Users → Batch update users, Display styling priority, and user permissions as a last-resort group of one.

Official chapters: Group permissions, How permissions are applied, User group promotions, Nodes and forums (Staff room example), Batch update users, Viewing and editing user profile data (docs.xenforo.com/manual/access-privileges/…, …/forums/nodes-forums, …/users/user-batch-update, …/users/user-profile). Ranks already owns trophies and banners as design. This one owns the permission consequences when those groups multiply.

Recap in one table, then stop retelling the primer

Official priority for a permission value, highest first:

Value	Meaning	Typical use at scale
Never	Overrides Yes. Official: “an overriding no.”	Discipline groups (warning actions, Restricted). Not Registered
Yes	Granted	Extra ability on a secondary role
No	Not granted (global default)	“This role does not add the ability”
Inherit	Node only. Lowest priority. Official: nodes default here	“Use whatever the parent / global already decided”

Official math: No + Yes = Yes. No + Never = Never. Yes + Never = Never. Numeric permissions take the highest value among groups and user permissions.

Official warning, still the one that wrecks large trees: Never is designed for discipline groups. Do not use it for the default Registered group.

Four groups you cannot remove: Unregistered / unconfirmed, Registered, Administrative, Moderating. Official: every registered human — admins and moderators included — keeps Registered as primary. New registrations always land there. Secondary groups are roles. If you find an admin whose primary is Administrative, fix that before you add group thirteen.

Node permissions start as Inherit. Customizing a value on a node is inherited by children unless they customize it again. Official exception: an inherited Never cannot be overridden, even by a child node.

That is the primer. The rest of this article is how you inspect and operate it when the matrix no longer fits on one screen.

Analyze permissions is the daily tool

Official: to confirm a user is receiving what you expect, use Groups & permissions → Analyze permissions. It shows the final yes/no and every permission that was considered. You can run it globally or on a specific node.

Use it as a ritual, not as a panic button.

After every group save that grants or Nevers a general permission. Pick a throwaway Registered account, a Moderator, and yourself. Analyze global. If Registered suddenly lost View or gained Submit content without approval, you did not finish.

After every private node. Analyze that node as a Registered member who is not in the extra group. Final View node must be no. Analyze as a member of the extra group. View node must be yes. Then check Post new thread — it should follow inheritance, not a second Yes you forgot you set.

After a promotion or a batch update. Promotions change group membership. Analyze does not run the promotion; it reads the result. If Analyze still looks like yesterday, the hourly job has not run or the user is not recently-active.

When a ticket says “I paid and I still cannot see it.” Do not open the node matrix first. Analyze that user on that node. The panel will name the group (or the user permission) that won. That is faster than reading twelve rows of Inherit.

Official user-profile chapter: there is also a Permissions tab on the admin user view that sets per-user values. Analyze is how you read the merge. Do not skip Analyze and stack another Yes on the user.

Community operations note, already in the performance and mistakes articles: rebuilding permissions across groups × nodes can lock a large tree. Add groups and rebuild off-peak. Analyze is cheap. Rebuild is not.

Official Staff room: private node the way the manual does it

The nodes article is the tree. This is the official private-forum recipe from Nodes and forums, because scale boards keep inventing a worse one.

Official goal: a forum visible only to Administrative and Moderating, hidden from everyone else.

Create the forum

1. Forums → Nodes → Add node.
2. Type: General discussion forum.
3. Title: Staff room (or your name). Save.

Restrict

1. On the node list, open Permissions for that forum.
2. Check Private node. Save.

Grant

1. In the user-group list on that permissions screen, open Administrative.
2. Set View node = Yes. Save.
3. Repeat for Moderating.

Official result: administrators and moderators can access Staff room; it is “completely hidden and inaccessible to all other users.”

The note everyone skips

Official, repeated on the permissions page and the premium-forum page:

The Private forum setting only affects the View node permission, without which all access to the node is denied. If a group is granted View node permission to a private node, the remainder of its permissions, such as Post new thread and Post replies, are inherited from their standard user group permissions — there is no need to explicitly grant these permissions again using node permissions.

So: Private is a view lock. It is not a blank permission sheet. A Moderator who can post globally can post in Staff room once they can view it. If you need Staff room to be read-only for Moderating, set Post new thread / Post replies on that node for Moderating. Do not re-Yes every forum permission “to be safe.” You are copying the global matrix into the node and guaranteeing drift.

Adapt the same recipe for a Subscribers lounge or a Clients node: Private on, View node = Yes only on the paying or client secondary group. Paid access is a user upgrade that adds that group. Do not use a promotion as a receipt.

Official parent-child trap, still in the nodes chapter: if a user cannot view a parent, they will never view the child, even if you override the child. Do not hide a category from Registered and then “open” a child forum to Registered. Put Staff room where its parent is visible to the people who should see it, or make the category private with the same View grants.

Node-specific moderators are not a group

Official nodes chapter: you can add a moderator for a specific node from that node’s moderators menu. They inherit the appointment on child nodes. That is a staff record plus extra tools on that branch. It is not a substitute for the Moderating group, and it is not how you hide a forum.

If only two people should see a vendor node, do not appoint them as node moderators and hope the node is private. Private + View node = Yes on a Vendor-acme group (or, last resort, on those two user permission rows) is the visibility model. Node moderators who cannot View still cannot moderate it. Analyze the node as each of them after you save.

Super moderators / global mods belong on the Moderating group plus the staff appointment. Do not clone Moderating into Mod-Support, Mod-Offtopic, Mod-Reports unless those roles have different permission values. Three groups with the same matrix is how Analyze becomes a novel. Prefer node-specific moderator appointments for “this person queues this forum,” and keep one Moderating group for the abilities.

Never traps that only appear at scale

Official purpose of Never: discipline. Warning actions that add a group as points climb are the textbook. You put Never on Post replies (or similar) on a Restricted group, you add people to Restricted, and no amount of Yes on VIP saves them.

Traps that show up after group twelve:

Never on Registered for one noisy permission. You meant “Registered should not start threads in Announcements.” You set Never globally. Official: it cannot be overridden, including on child nodes, including by Administrative if that Never is in a group they belong to — and they belong to Registered. Restrict the node. The starter article already said this. At scale you do it with a category of announcement nodes, not with Never.

Never on a cosmetic rank. Veteran was supposed to be a banner. Someone set Never on an attach limit “because veterans should not dump ZIPs.” Now a veteran admin is stuck, and Analyze shows Veteran, not Restricted. Cosmetic groups stay display-only. The ranks article already begged you. Here it is a restore-from-backup event.

Never on Moderating “so mods cannot delete.” Then you add the same people to Administrative for ACP and wonder why front-end delete is still dead. Never on Moderating wins. Use No on Moderating and Yes on a smaller Lead moderators secondary if you need a split. Or use moderator permissions on the staff record — official staff systems exist so you do not Never the whole role.

Two discipline groups both using Never, plus a warning action that stacks them. Analyze will show Never from the first group and you will delete the wrong one. One Restricted group. Warning actions add that group. One place to look.

Inheriting Never into a private node you later “open.” Official: Never cannot be overridden by a child. If a parent category has Never View for Registered, Private + Yes on a child will not save Registered. Rebuild the parent.

When you think you need Never and the group is not Restricted, you almost always need No / Inherit on the broad group and Yes on the narrow one, or a private node.

Warning actions are how Restricted should fill

Official warnings chapter: warning actions can add user groups as points climb. That is the intended Never pipeline. You do not hand-edit twelve profiles after a raid. You define:

1. A Restricted group with Never on the actions you are removing (post, attach, conversation — only what you mean).
2. A warning action at N points that adds Restricted.
3. Staff who apply warnings, not staff who edit secondary groups at 01:00.

Analyze a warned account on a public node. The winning Never should name Restricted, not Veteran, not Registered. If it names Registered, you put the hammer on the species again.

When the points expire or staff lift the warning, the action should remove the group. Confirm that on a test account before you use it in public. Official warning-actions wording includes adding groups; treat removal as part of the same action design, and batch-update if you inherit a mess.

Numeric permissions: highest wins

Official: for numeric permissions, the highest value among all groups and user permissions is used. Attachments per post, maximum recipients, search intervals — whatever your matrix shows as a number — do not average and do not take the most restrictive unless that restrictive value is a Never on the related ability.

Scale implication: a Subscriber group with a high attach limit and a Restricted group that only Nevers Post replies will still have the high attach limit if they can post at all. If discipline must also cap attaches, set that numeric value on Restricted and confirm Analyze. Do not assume Never on one permission zeroes the others.

Do not put a “premium attach limit” on a cosmetic rank. That couples a banner promotion to a numeric rebuild. Put numbers on Subscriber (paid) or on Verified (earned), and leave Veteran pretty.

Display styling priority is not a permission

Official groups chapter: besides permissions, a group can change how users look. If a user is in multiple groups, the group with the highest Display styling priority wins for most of these:

1. User title override — title from this group instead of the title ladder. A per-user custom title still beats both.
2. User name CSS — colour or flourish. Official: not used in all scenarios.
3. User banners — banner below the name. More options: Setup → Options → User options → User banners.

Write the numbers down. Staff (Administrative, Moderating) sit above paid and above cosmetic ranks, so a moderator is never “Newbie” in the chip. Gaps of 10 or 100 — 10, 20, 30 or 100, 200, 300 — so you can insert 250 later.

Priority does not pick a permission winner. Yes still beats No regardless of who has the prettier banner. Mixing those two ideas is how a Subscriber with priority 1000 still cannot see a lounge you forgot to grant.

A rank group with a banner and no extra Yes/Never does not change Analyze. That is the point. The moment Veteran also has View on a lounge, every promotion into Veteran is a permission rebuild. Document it, do it off-peak, and keep that lounge off the default tree if you can.

Promotions at scale: hourly, recently-active, not a census

Official: Groups & permissions → User group promotions. Promotions automatically add members to groups to change title, username styling, or permissions.

Official utility list, because the name is too small: membership segmentation, birthday identification, badges for contributors, username styling for new users. The official new user restrictions example is the one you will actually ship: Registered cannot Submit content without approval; a Verified member group sets that permission to Yes; a Verified promotion adds that group after User has posted at least X messages = 5. First five posts wait in the queue. After the job runs, they post normally. Official: “It is not instantaneous.”

Rules the manual will enforce whether you like them or not

Empty criteria = never awarded automatically. Official. A promotion you saved as a draft with no criteria is not “everyone.” It is no one.

The job is hourly. Official: a cron task every hour. Need it now: Tools → Cron entries → User group promotions (run it). The new-user example is why a sixth post can still sit in the queue for 59 minutes.

Recently-active users only. Official, by design: inactive members are not processed, and existing promotions are not removed, until they become active again. This is the scale surprise. You change a promotion at 10:00. The lurker who last visited in March still has last month’s groups. They are not a bug. They are the rule.

Disable does not demote. Official note: disabling stops new awards. It does not remove the group from people already promoted. If you needed a rollback, disable is the wrong button.

Manual add on the profile wins. Official: if they no longer match, they are removed unless membership came from an admin editing the profile or from another matching promotion. Hand-adding Verified member means the promotion will not take it back. That is either a staff gift or a leak.

Manual promote / prohibit on Manage promoted users overrides criteria and stays until you undo it. Official: manually demoted users are not eligible for that promotion even if they match. The history row says Promotion disabled. Delete again to re-enable eligibility.

Undoing a live promotion

Official options, in their order:

1. If the target group existed only for this promotion, delete the group, then the promotion.
2. If you want the group to remain empty, batch update everyone in it and remove membership, then delete the promotion.
3. If the group is shared with other promotions, leave the promotion active and change criteria so nobody matches (official example: registered before January 1990). As people become active, the job removes the group.

Deleting the promotion definition does not undo assignments. Internalize that before you “clean up” the list.

When promotions are the wrong tool

Official alternative for “apply this group to the entire register, including lurkers”: batch update, not a promotion. If finance needs every account with 1,000 posts in Veteran today, including the dead ones, that is Users → Batch update users. The next time those people log in, a promotion would have caught them anyway. The census will not wait.

Do not promote into a paid node. That is a user upgrade. Do not promote into Administrative. That is a staff record. Do not promote a custom field into View node on a private tree unless you accept the rebuild and the Analyze surface.

Birthday and other “utility” promotions

Official promotions chapter lists birthday identification as a normal use. Official birthday example (separate manual page): a Birthday today group with a very high Display styling priority, plus a promotion that adds that group while the criteria match. Next day they fail the criteria, the hourly job removes the group — if they are recently-active. A lurker whose birthday was Tuesday still wears the banner until they log in. That is the recently-active rule, not a bug. Do not put permissions on Birthday today.

Same pattern for “new user styling,” A/B segmentation, or a temporary event badge. High priority, no Yes/Never, criteria that expire. If the banner sticks, they have not been active, or someone hand-added the group on the profile (manual add wins).

User state is not a group

Official profile chapter: User state other than Valid “will effectively apply the permissions granted by the Unregistered / unconfirmed user group, rather than the standard Registered group.” Rejected, email-unconfirmed, and similar states are not a secondary group you Analyze as Registered.

Scale implication: a promotion that matches “Registered + 5 posts” will not save an account that is still awaiting email. Batch update that adds Verified member should also filter user state = Valid, or you will decorate accounts that still have guest-like permissions. Official: the Unregistered / unconfirmed group is guests and users whose account is not in a confirmed/valid state.

When you “ban” with a state change instead of the ban system, you are swapping them onto the guest matrix. Know which tool you used. Analyze will look like a guest even though a profile exists.

Batch update: the census tool

Official: Users → Batch update users. Use the user criteria searcher, then apply changes: primary and secondary groups, remove memberships, user state, security lock, and others.

This is how you:

• Remove a retired group from everyone, including lurkers
• Add Verified member to the historic register after you introduce the new-user queue (or you will have ten-year members waiting on post #5)
• Pull Restricted off people after an amnesty
• Fix primary group = Registered for everyone who was “promoted” the wrong way in 2022

Criteria are the same engine notices and promotions use. You can filter on group membership, message counts, and user fields. Preview the match count. If it is the whole board and you meant a slice, stop.

Batch update is powerful and boring. It is not undo. Export or note the criteria before you run it. Off-peak. Then Analyze three people who should have changed and one who should not.

Official: setting primary group is possible here. Official groups chapter still does not want you to set it to anything but Registered. A batch that “makes VIP primary” is how you create a second species. Add VIP as secondary. Leave primary alone.

User permissions: the last group of one

Official permissions page: User permissions are an optional extra set on specific users. Used for things like moderator permissions. Official recommendation: if you will apply the same thing to multiple users, create a group.

Official profile chapter, Permissions section: this is “rarely required.” Inheritance treats the user as belonging to primary + secondaries + a final group that has only one member (themselves). Same math: any Yes wins over No; any Never wins over Yes. User permissions do not outrank groups. A Never on Registered still kills a Yes on the user.

So the last-resort cases are real and small:

• One vendor account that may post in a single private node and must not have the whole Clients group
• One founder who must keep a quirky Yes you refuse to put on Administrative
• A temporary grant you will date in the staff room and delete

If you are setting the same user permission on a fifth account, you waited too long to make a group. Analyze will show five snowflakes and no name.

Admin editing another admin: official profile chapter requires your password to confirm. That is not a permission quirk; it is a safety latch. Use it as a reminder that user-level changes on staff are audited whether you meant them to be or not.

The Display user as staff checkbox on the profile is official display only. It does not grant ACP or moderator tools. Staff rights stay on the moderator / administrator systems plus the Moderating / Administrative groups.

A scale group map that does not rot

Start from the starter four. Add groups only when you can name the Yes/Never or the banner they own.

Group	Primary?	Permissions?	How people get it	Notes
Unregistered / unconfirmed	system	Guest baseline	System	Guests + non-valid states
Registered	yes, always	Public baseline. Official new-user example: Submit content without approval = No if you run a queue	Registration	Never put Never here
Verified member	secondary	Submit content without approval = Yes	Promotion after N posts; batch the historic register	Official recipe
Moderating	secondary	Moderation extras; View on Staff room	Staff appointment	Styling priority above ranks
Administrative	secondary	ACP-facing extras; View on Staff room	Staff appointment	Primary remains Registered
Subscriber / Client	secondary	View on a private lounge only	User upgrade	Not a promotion
Veteran / Regular	secondary	None if you can help it	Promotion on messages / reaction score	Banner + priority only
Restricted	secondary	Never on the actions you are taking away	Warning action or staff add	One discipline group
Birthday (optional)	secondary	None	Official-style birthday promotion	High styling priority, short-lived

You do not need all of these. You need the ones you can explain in a staff thread. Merge two groups that have the same Analyze result. Official: if two groups require nearly identical permissions, merge them or extract the shared part into a third group.

Node tree at scale: public categories inherit Registered. Staff room is private + View for staff groups. Paid lounge is private + View for Subscriber. Do not Revoke View on Registered for twenty individual forums when one private category would do.

Moderation queues get easier when Verified is a group, not a vibe. Onboarding should tell new members that the first N posts wait. The promotion is not instant; say so.

Worked: turning on Verified without stranding veterans

Official new-user walkthrough, with the scale steps the short example skips.

1. Groups & permissions → User groups → Registered. Set Submit content without approval = No. Save. (Official new-user page also writes this as Users & groups → User groups → Registered — same screen, later IA.)
2. Add user group Verified member. Set Submit content without approval = Yes. No banner required. Save.
3. Users → Batch update users. Criteria: message count at least 5 (or your N), user state Valid. Action: add secondary Verified member. Run off-peak. This is the census the hourly job will not do.
4. Groups & permissions → User group promotions → Add promotion. Title Verified. Add user to Verified member. Criteria: User has posted at least X messages = 5. Save.
5. Tools → Cron entries → User group promotions once, so people who are online this hour move.
6. Analyze: a brand-new Registered account — cannot submit without approval. A 5-post active account — can. A 5,000-post lurker you batched — can, even before they log in.
7. Staff room post: “First five posts are queued. Promotion is hourly.”

If you skip step 3, every quiet regular is a new user the moment you flip Registered to No. That ticket flood is on you, not on cron.

Checklist

• Every human still has Registered as primary (Analyze or a user search, not vibes)
• Never exists only on discipline groups, never on Registered, never on a banner rank
• Staff room: official Private node + View node = Yes on Administrative and Moderating only
• You did not re-Yes every forum permission on that private node
• Parents of private nodes are visible to the people who should enter the child
• Analyze permissions run globally and on the private node for a Registered, a mod, and a subscriber
• Display styling priority written down; staff above paid above cosmetic
• Cosmetic ranks have no extra Yes/Never
• Promotions have real criteria (empty = never)
• You know disable ≠ demote
• Historic register batched when a new required group appears
• Hourly cron understood; Tools → Cron entries → User group promotions used for “now”
• User-level permissions counted; a fifth copy becomes a group
• Rebuilds / large batch updates off-peak

Takeaways

• The starter four groups still exist. Scale is Analyze, private nodes, promotions, batch, and priority — not a fifteenth copy of Registered.
• Groups & permissions → Analyze permissions is how you read the merge. Use it after every interesting save.
• Official Staff room: Private node, then View node = Yes for staff groups. Private only locks View; Post inherits.
• Never is a discipline hammer. Official: do not put it on Registered. It cannot be overridden by a child node.
• Display styling priority picks banners and title overrides. It does not pick permission winners.
• Promotions run hourly and only for recently-active users. Empty criteria never fire. Disable does not demote. Undo with criteria, batch, or deleting a purpose-built group.
• Users → Batch update users is the census. Use it when lurkers must change today.
• User permissions are a group of one with the same Yes/Never math. Last resort, then a real group.

If you cannot explain a group in one sentence, Analyze will explain it in twenty. Delete the group instead.