A large XenForo board does not fail because it lacks a “moderation suite.” It fails because every trusted member is a global moderator, the root Admin account is arguing in Off-topic, and someone saves a primary-group change at 20:00. The stock tools are enough: node moderators, an approval queue, IP logs, warning points that feed a stripped group, soft-delete, user states, and a spam-trigger log. The workflow is who may touch what, and in what order, before the board is a queue nobody wants.
This is not the permissions map and it is not engagement. Those articles already told you Registered stays primary and that a like is not a second session. This one is the shift: how a 50-forum tree stays staffed without turning the ACP into a second job.
Staff the tree, not the whole site
Official 2.3 has four groups you cannot delete: Unregistered / unconfirmed, Registered, Administrative, Moderating. Official recommendation, again: every human — including staff — keeps Registered as primary. Moderating and Administrative are secondary. An admin who also works the queue belongs to all three. That is not politics. That is so the next add-on you install only has one baseline to edit.
Node-specific moderators are the official scale valve. On the node, open the moderators menu → add moderator. Type the username. Pick the permissions for that branch. Official docs: they inherit downward to children. That is how FiveM staff moderate play/ and never see billing. It is also how you avoid a twelve-person super-mod group that can hard-delete the rules thread.
The exact ACP path to add a global (“super”) moderator is not in the official notebook we queried. In the product, global moderators still exist as users with the Moderating secondary group and site-wide moderator permissions. Use that group for people who must see every report and every private node. Use node moderators for everyone else. If a node is Private, official rule: grant View node = Yes to Moderating and Administrative or those people are not staff on that branch. They cannot moderate a room they cannot open.
When you edit anyone in the Administrative group, official docs: the ACP asks for your password. That is the last chance to notice you have the wrong profile open.
The Admin account is not a person
Community consensus on large boards is sharper than the manual. The root Admin account is a system actor: announcements, upgrade notes, structured warnings. It is not a joke account. When the badge that can suspend you is also posting memes, people stop disagreeing. Staff post as themselves, without the nuclear badge, when they are being members. Official warnings still go out from a staff identity the queue can search.
Community sources also name Moderator Panel by Andrew and a Protected Users list so a junior moderator cannot ban an admin profile. That is an add-on, not a requirement. The stock version of the same idea: do not hand global ban permission to node mods, and do not leave the Admin account logged in on a shared machine.
What the queue is for
Official docs are thin on the approval-queue UI. They do say unapproved and soft-deleted threads live in a non-visible discussion_state and go to the approval queue, and that the chrome includes approve / unapprove. The whitelist article already recorded the community limit: the 2.3 queue pulls a page at a time (about 50). It is a spam tool, not an HR inbox. Do not run a 400-thread application season through it.
What should land there on a large board, from community practice plus the official “moderate new threads” checkbox on a node:
| Hold this | Why | Do not hold this |
|---|---|---|
| First posts that contain a URL, until the account has N messages | Official-adjacent community rule: unestablished + link = queue | Every thread in Introductions |
| Registrations your anti-spam integration flags | Community: CleanTalk (and similar) can send suspects to the queue instead of letting them in | Every valid email confirm |
| A staff-only apply forum you chose to moderate | You already designed that queue | The entire public tree “until we hire more mods” |
If the public tree is on fire, you have a spam problem or a culture problem. Turning on Moderate new threads everywhere creates a second forum only staff can see, and it will drown. Prefer: hold links from new accounts, hold registrations that fail a reputation check, and let established members post. Reports then catch the rest — even though the official notebook we queried does not document the report-queue workflow. The product still has Report on a post and a staff report list. Work that list. Do not invent an assignment ballet this article cannot cite.
Community spam setup that does not need a new add-on:
- Stop unestablished accounts filling location / occupation / website until they have one real post.
- Spam phrases in the ACP: community example is
[url*(not only[url=) so people who break the tag still match. - Tools → Spam trigger log. First stop on a shift. Patterns show up there before they show up in the queue.
Named add-ons in those sources, if you outgrow the log: CleanTalk Anti-Spam, Spaminator (Ozzy47) for registrations that skip the browser, Moderator Panel by Andrew. They are optional. They are not a substitute for “Registered stays primary” and a node-mod map.
Discipline that does not require a novel
Official 2.3 names a warning system. The documented hook: a disciplinary user group whose rights you strip with Never, applied when the member reaches a number of warning points. The warning-action editor, decay, and “at 5 points temp-ban” ladder are not in the official notebook. Do not copy a ladder from a 2018 blog. Build one on staging and write it in a staff-only page:
- What a warning is for (the public reason members will read).
- How many points that reason is worth.
- Which group they enter at which total, and which Nevers that group has (post, start threads, upload).
- Whether points expire. If you cannot say, they do not expire, and you will stack people into a hole.
Ban, disable, reject, and “spam cleaner” as separate ACP verbs are not fully documented in that notebook. What is documented, and what you should actually click on a large board:
Soft-delete hides the post or thread (discussion_state is no longer visible). Reversible. This is the default public action. Official REST split: thread:write covers soft-delete; thread:delete_hard is the destructive scope. If your staff cannot tell those apart, they should not have hard-delete.
Hard-delete removes the row. Official: undo is a backup. On a large board, hard-delete is for illegal content and for the spam account you already copied an IP from. It is not for a bad take.
IP addresses on the user edit screen: official More users control next to a log line. That is how you find the second account. Official: you can ban or discourage an IP from that list. Discouraged (on Users → Search for users, then the profile) is the official “make this connection miserable without a drama-ban” switch. Use it for the proxy that keeps registering. Do not use it on a member you are still talking to.
Security lock on the same profile: official options Locked: User must change password and Locked: User must reset password. Compromised account. Not a punishment. Tell them in a conversation they can still read.
User states. Official: Valid means they clicked the confirm mail and get Registered rights. Every other state uses the Unregistered / unconfirmed permission set. A “disabled” or “rejected” account that can still post is a permission bug, not a state bug. Search non-Valid users on a Monday. Do not promote anyone whose state is not Valid.
Move, merge, and reply-ban exist in the product (official button-manager icons include move and merge). Step-by-step workflows are not in the official notebook. Use them as you already do: move is not a delete, merge is not a warning, a reply-ban is a thread-local mute. Write those three sentences in the staff handbook so a node mod in one game section does not invent a fourth.
Prefixes are not a punishment
Community sources push thread prefixes as a member sorting tool: a wide node plus prefixes, instead of a deep tree that multiplies permission rebuilds. Automated “must pick a prefix” rules are mentioned. Computational note from those write-ups: prefixes hit an index; they do not rebuild the global permission cache.
That is the opposite of using prefixes as a staff-only state machine on the public tree. The whitelist article already used staff prefixes on an apply forum. Do not paint “Warned” on a public support thread. Soft-delete or move it. Prefixes that members filter on should describe the topic, not the member.
What locks a large board
This is the same math as the performance article. It belongs here because staff cause it.
Permission compilation scales with groups × nodes. Community numbers: ~80 nodes and ~60 groups → two to four minutes after a primary-group save; ~700 nodes → timeouts and locked tables. So:
- Do not create a group per mood. Do not create a node per thread topic.
- Do not change primary groups at peak. Schedule it. Say so in staff chat.
- Node-mod assignments are cheaper than another global group.
Also from those sources, not moderation-specific but they will page you: template rebuilds on heavy styles (Too many open files — raise open_files_limit or rebuild from CLI), MySQL query_cache_type left on, innodb_flush_log_at_trx_commit = 1 during a registration wave. Official developer warning: do not fetch() every post on a large board; use the job system. The same rule applies to any “clean up all spam posts” script a well-meaning admin pastes into Tools.
Mass bans are not listed in the notebook as a lockup cause. Still: ban the account, then the IP, then run the cleaner if you use one. Do not invent a batch that touches 4,000 rows on the web request.
First 30 minutes of the duty shift
Community order, adapted to stock tools. If you run Andrew’s panel, it is step 4’s dashboard. If you do not, the stock report list and the approval queue are the dashboard.
| Minutes | Action | Done looks like |
|---|---|---|
| 0–5 | Log in as you, not as Admin. Confirm you can see the private staff node. | Badge you will post with is the human one |
| 5–15 | Tools → Spam trigger log. Then non-Valid registrations. | You can name the current spam pattern or say “quiet” |
| 15–20 | Approval queue. Approve humans. Reject link-dumps from accounts with zero real posts. | Queue is a page, not a career |
| 20–25 | Reports (stock list or the panel). Soft-delete what must vanish. Warn only when the handbook has a reason. | No report older than the shift SLA you wrote |
| 25–30 | One IP More users check on anything that smelled like a sock. Security-lock a hijack. Do not save a group or node permission in this half hour. | You did not start a rebuild |
After the half hour you are in the forums, as a person, on the nodes you own. Escalation to an admin is: illegal content, a staff member, or a permission change. Everything else is a warning, a move, or a no.
What “large” means here
If one person can still read every new thread, you do not have a large-forum problem. You have an onboarding problem — go back to the first 30 days. This article starts when:
- More than one room needs its own staff who must not see the other rooms.
- The approval queue can fill faster than one volunteer in one timezone.
- A permission save is a maintenance window, not a reflex.
You do not need 50,000 users. You need a tree that already hurts when everyone is global.
Permissions you actually tick on a node mod
Official add-moderator form is a list you walk, not a preset named “section lead.” A working default for a game-section lead:
- View, edit, delete (soft), move, merge on this branch
- Warn, if you trust them with points that feed a global group
- Approve / unapprove, if this branch uses the queue
- Not ban, not edit users, not hard-delete, not change node permissions
Ban and hard-delete stay on the small global set. If a section lead needs a ban, they write the reason in the staff node and a global mod clicks. That is slower. That is the point. The whitelist article already used node mods on an apply forum the same way.
A quiet spam morning
You open the trigger log. Forty hits, all example.ru in the website field, all from two /24s. You do not turn on Moderate new threads globally. You:
- Ban the two IPs (or discourage them if they are a shared mobile gateway — official discourage exists for this ambiguity).
- Confirm the website profile field is still locked for unestablished accounts.
- Add a spam phrase that matches the payload you actually saw, not a phrase that will eat
[url]in a support post. - Reject the queued registrations. Leave Valid humans alone.
- Write two lines in the staff node: IPs, phrase, “watch until Friday.”
That is a shift. Installing a new anti-spam add-on in the same hour is how you also break registration.
Escalation, written down
Put this on the staff page. Node mods should not have to guess.
| Situation | Who | Tool |
|---|---|---|
| Off-topic in the right room | Node mod | Move. No warning |
| Same member, third time, written reason | Node mod if they may warn; else global | Warning points |
| Sock farm, same IP | Global | More users, then ban / discourage |
| Hijacked account | Global | Security lock, then a conversation |
| Staff member is the problem | Admin only | Not a public warning |
| Legal / CSAM / credible threat | Admin, then host / law as your policy says | Hard-delete + notes off-site |
| “We need a new group for this mood” | Admin, off-peak, after you failed a prefix | Permission rebuild is a window |
If it is not in the table, the answer is no until the next staff meeting. A large board dies when every shift invents policy.
Daily checklist (stock)
- You are not typed in as Admin unless you are announcing
- Spam trigger log scanned
- Non-Valid users scanned; humans confirmed, the rest left restricted
- Approval queue emptied to one page
- Reports touched; soft-delete default; hard-delete only when you would restore from backup to undo it
- One suspicious profile: IP addresses → More users
- Discouraged / IP ban only for the connection, security lock only for the hijack
- Warning points only with a written reason and a group that actually has Nevers
- Groups & permissions → Analyze permissions after any staff-group change (off-peak)
- No primary-group, node-permission, or template rebuild during the duty window
- Node-mod map still matches the tree
What this article will not do
It will not publish a points ladder the notebooks did not contain. It will not document a report-assignment ballet official docs skipped. It will not tell you how many moderators a 50,000-user board “needs.” Hire until the queue is a page and the reports are younger than your SLA.
It will not replace a culture document. Tools do not make people kind. They make the next shift able to see what the last shift did: a soft-deleted post, a warning with a reason, an IP two accounts share, a node mod who cannot ban the admin.
Staff the branch. Hold new-account links. Soft-delete in public. Change groups on a calendar. Leave the Admin account in the drawer. That is a large XenForo forum. The add-on store can wait until the shift already works.