XenForo whitelist requests: a stock application workflow

A whitelist is a decision, not a form. Someone asks to get in. Staff decide. A secondary user group opens the room they could not see yesterday. XenForo 2.3 will hold the queue, the questions, and the locked forum. It will not watch a thread prefix and add the applicant to a group. If you install a whitelist plugin because you wanted that last click to be automatic, you skipped the half the board already does.

This is the stock workflow. It is the same pattern the official manual uses for a staff room and a premium forum: a Private node, View node set to Yes on one extra group, and a human (or a payment) who puts people in that group. The server listing article already told you not to hang an application off a directory thread. This article is that other job.

What the whitelist is actually gating

Say the word out loud and three different products answer. Mix them and you will build the wrong tree.

Gate	Applicant wants	After approval they get	Stock shape
Game / RP access	A character, a FiveM slot, a Minecraft world	A group that can see the lore forum, the application-only Discord field, the staff-verified listing	Apply forum + Whitelisted group + private play rooms
Private discussion	The subscriber / alumni / staff-adjacent room	View node on one private forum	Official premium-content pattern, minus the payment
Trust / verified	A badge and fewer limits	Banner, upload limits, fewer spam holds	Optional. Often a promotion on post count, not a human interview

A listing thread that says “whitelist required” is a label. The application is a workflow. Keep them in different forums. A FiveM directory can carry a Whitelist prefix so strangers filter the server list. The form that asks for hours, age band, and a character name lives here.

Do not call a post-count promotion a whitelist. Groups & permissions > User group promotions will add a secondary group when a member has been registered a year or has a reaction score over 100. That is a ladder. A whitelist is a person who read the answers and said yes. Use promotions for the ladder. Use a human for the interview.

Four architectures — pick one

Stock XenForo gives you four honest ways to collect “please let me in.” Only one of them is a queue staff can work on Monday morning.

Shape	What the application is	Who grants the group	When it is right
Thread queue	One discussion thread with required fields and a staff prefix	Staff, in Users → Search for users, secondary groups	Default. FiveM, Minecraft, RP, any interview
User fields	Answers on the profile / registration form	Staff reading User details	Two or three short facts you want on every member, not a six-question app
Promotion	Nothing. Criteria fire on a cron	The hourly User group promotions job	Measurable bars only: days registered, messages, reactions, avatar
User upgrade	A payment	Users > User customization > User upgrades adds Additional user groups	They are buying the room. Official premium-content walkthrough

The rest of this article builds the thread queue. It reuses the official Private node walkthrough. It does not pretend a prefix change is a promotion criterion. That criterion is not in the manual, and a 2025 community thread asking for “Approved prefix → add to group” is still an add-on request.

Custom user fields (Users in the ACP) are the wrong container for a long application. They sit on the profile, they can show next to every post, and every member has one set of answers. That is useful for “Discord handle” or “timezone.” It is a mess for “tell us your character’s backstory” that you only want staff to see during week one. Put the story on the thread. Put the handle on the user if you still need it after they are in.

Groups first, then rooms

XenForo treats groups as roles. The four you cannot delete are Unregistered / unconfirmed, Registered, Administrative, and Moderating. Every confirmed member — including the people who will approve applications — should keep Registered as the primary group. The official group manual is blunt about this. Change primary group to Whitelisted and you will spend the next add-on install editing two baselines instead of one.

Create one extra group:

1. Groups and permissions > User groups > Add user group.
2. Title: Whitelisted. Leave the permission matrix at defaults. You are not duplicating Registered here.
3. Optional: a user banner and a modest Display styling priority so approved members read as approved in posts. Do not steal Administrative’s styling.
4. Save.

You do not need an Applicant group. Anyone who can post in the apply forum is already an applicant. A third group is another row on every permission rebuild. The community blueprint that talks about rebuild cost (C ∝ users groups × nodes) is describing what happens when you invent a group for every mood.

Staff already have Moderating or Administrative as secondary groups. Give those groups View node on the locked rooms the same way you give it to Whitelisted, or they will be locked out of the play forum they are supposed to moderate. The official premium-content note says the same thing about Subscribers: do not forget staff.

Never put Never on Registered to “keep them out of the play forum.” Never is for a disciplinary group. It wins over Yes on Whitelisted, so the member you just approved still cannot see the room. Everyday denial is Not set (No) on the broad group plus Yes on the narrow one — or, cleaner, the Private node flag, which ignores the global baseline and waits for an explicit View node = Yes. Confirm the result with Groups & permissions > Analyze permissions on a dummy applicant, then on the same account after you add Whitelisted.

The official private-node pattern, used as a whitelist

The manual’s staff-room example and its premium-content example are the same five clicks. We change the group name.

Locked room (the thing they cannot see until they are in):

1. Forums > Nodes > Add node. Type: General discussion forum. Title something a stranger understands — Play, After whitelist, Lore. URL portion you will not rename: play, lore. Parent: a category, not the apply forum.
2. On the node list, Permissions for that forum.
3. Check Private node. Save.
4. Open Whitelisted. Set View node to Yes. Save.
5. Repeat View node = Yes for Administrative and Moderating.

Private node only flips View node. Once that is Yes, Post new thread and Post replies inherit from the group’s global permissions. You do not have to re-grant them on the node unless you want the locked room to be read-only for new members.

Apply forum (the queue):

1. Another General discussion forum. Title: Whitelist applications. URL portion: apply. Parent: the same category, or a public “Join” category if you want guests to see that applications exist.
2. Do not make this one private if Registered must post in it. A private apply forum that only staff can view is a forum nobody can apply to.
3. Permissions: Registered may View node, Post new thread, Post replies. They may not edit others’ threads, change prefixes you marked staff-only, or see a staff-only custom field. Moderating may edit, prefix, move, and soft-delete.

Two inheritance rules from the nodes guide will ruin this if you ignore them:

• If a user cannot view the parent, they cannot view the child. Do not hide the category and then grant View on Play.
• Display-in-list is not a permission. Unchecking it hides the row from the forum list. It does not lock the URL. Use Private node (or a real overlay) when the content is the secret.

One apply forum. One locked forum (or one per game if each game has its own staff — not one per applicant). Prefixes sort the queue. A node per pending application is how you get a mall of empty rooms and a permission rebuild that takes minutes. The community write-up on broad nodes versus deep trees is about this exact failure.

The application is a discussion thread

Use a General discussion forum. Do not reach for the other thread types.

Type	What it optimises for	Why it is wrong here
Discussion	A first post plus replies, last-post bumping	Right. Staff ask follow-ups in the thread
Article	A prominent first post, replies as comments	You need a conversation, not a magazine page
Question	Answers and an accepted solution	Approval is not a “best answer”
Suggestion	Votes; suggestion threads only live in suggestion forums	A popularity contest, not a queue. Same trap as voting for servers

A thread may have one prefix. Set the prefix vocabulary to status, not to game. Game is a forum or a field.

Forums > Thread prefixes. Create four. Applicable forums: only apply.

Prefix	Usable by user groups	Description (under the title)	Usage help (on create)
Pending	Registered (and staff)	This application is waiting for staff.	Pick this if you are submitting. Staff will change it.
Interview	Moderating, Administrative	Staff have a question. Reply in this thread.	Staff only.
Approved	Moderating, Administrative	This member was added to the Whitelisted group.	Staff only. Changing this prefix does not grant the group.
Denied	Moderating, Administrative	This application was declined.	Staff only. Say why in a reply.

Usable by user groups is how you stop a hopeful applicant from prefixing their own thread Approved. Applicable forums keeps these four words out of the directory and out of General. The prefix is part of the title in almost every context, including search-engine titles, so do not use cute slang.

If you want a prefix required in practice, say so in the forum description and in the Pending usage help. Stock XenForo will still let someone skip it unless you moderate the ones that arrive bare. That is cheaper than a fifth prefix called “Forgot.”

Custom thread fields are the form

Forums > Custom thread fields. These belong to the first post, not to replies. Replies will not be asked again. That is what you want: the card stays stable while staff talk underneath.

Official display locations:

1. Before message — above the first post body.
2. After message — below it.
3. Thread status block — a small block above the first post, on every page of the thread.

Use the thread status block for the facts staff scan: age band, hours, Discord, character name, “have you been banned elsewhere.” Put the long “why this community” answer in the message body, or in a multi-line text field after the message. Do not dump a novel into the status block.

Applicable forums: apply only. Editable by user groups: Registered can fill the public fields; only Moderating / Administrative can fill staff_notes.

A starter set for a game / RP gate:

Field ID	Type	Required	Display	Who edits	Why it exists
age_band	Radio (13–15 / 16–17 / 18+)	Yes	Status block	Applicant	You cannot un-ask this later. Do not store a birthday if a band will do.
hours_available	Radio (weeknights / weekends / daily)	Yes	Status block	Applicant	Scheduling, not a loyalty test.
discord_handle	Single-line text	Yes	Status block	Applicant	How you interview. Not a member-count brag.
character_name	Single-line text	If you run RP	Status block	Applicant	One name. The backstory is the first post.
prior_bans	Radio (no / yes, explained in body)	Yes	Status block	Applicant	A checkbox they can lie on is still better than nothing.
staff_notes	Multi-line text	No	After message, or leave display off if you only need it in the ACP	Staff	“Joined on Tuesday, voice was fine.” Not visible as a field applicants can type into.

Field IDs are alphanumeric and cannot be changed. Pick boring ones. The same family of inputs as custom user fields: text, radios, checkboxes. Radios for a closed set. Checkboxes only when several things can be true at once. No “player count” field. No “I agree I am a good person” checkbox that nobody reads.

Custom user fields stay for facts you still need after the thread is closed: a Discord handle you want on the profile, a timezone, a pronouns dropdown you later promote on. They can show with messages or on the profile. They can be edited by the member later, which is exactly why they are a bad place for “tell us about the time you were banned.” That answer should freeze on the application thread.

Privacy: stock XenForo will not hide the other applicants

This is the limitation people buy plugins to avoid. Be honest on day one.

If Registered can View node on apply, they can read every visible application in that forum. There is no stock permission that means “view only my own threads.” The official permission matrix does not have that row.

You have four honest policies:

Public queue. Everyone sees every application. Common on RP boards. Social pressure does some of the work. Do not ask for a legal name, a phone number, or a school. Age band, not date of birth. Discord handle is already semi-public.

Queue that never goes visible. On the node, enable Moderate new threads (Advanced). New applications land unapproved. Regular members do not see them in the forum list. Staff with moderator rights work them from the approval queue and from the forum (moderators see unapproved content). You then do not approve the thread to the public. You add the group, set the prefix, and leave the discussion unapproved or soft-deleted. This is ugly. The approval queue in 2.3 also only pulls a page of items at a time (community consensus: 50). It is a spam tool, not an HR inbox.

Staff-only apply forum plus a conversation. The apply node is Private to staff. Applicants open a conversation with a staff account and paste answers. You have no prefix filter, no custom thread fields, no forum view. You have a mailbox.

An add-on. If “only author + staff see this application” is the product, stock XenForo is the wrong tool. Buy or write that. Do not fake it with a page node of HTML forms.

Whatever you pick, write it in the forum description. Applicants who thought their ban history was private will not forgive a public thread.

Do not collect more than you will defend. Custom user fields can be exported with Users > Data portability. Thread fields live on the first post. Either way, a leaked application is your problem. The permissions starter is the map for who can see a node. It will not anonymise a field you put in the status block.

Review is a person, then a group edit

A working Monday:

1. Open apply. Filter by prefix Pending (or Interview).
2. Read the status block. Open Discord if that is the interview. Ask follow-ups in the thread so the next moderator can see them.
3. Decide.
4. Users > Search for users (or the username on the first post). Open the account. Under User details, add Whitelisted to the secondary groups. Save.
5. Change the thread prefix to Approved. Lock the thread if you do not want a victory lap. Reply once: “You are in. The Play forum is on the list.”
6. Groups & permissions > Analyze permissions on that username, for the play node. You want View node = Yes coming from Whitelisted, not from a leftover user permission.

Denied is the same path without step 4. Prefix Denied. Reply with a reason you can repeat. Do not use Never on Registered. Do not change their primary group to a punishment group unless you already have a disciplinary group designed for Never.

Changing the prefix does not add the group. There is no stock listener that maps Approved → Whitelisted. The developer manual will tell you that an add-on can hook entity_post_save on XF\Entity\Thread and edit the user. That is a customisation. It is not an ACP checkbox. If you skip step 4 and only flip the prefix, the member will read “Approved” and still bounce off the private node. They will be right to be angry.

Manual group membership sticks. That matters when you also run promotions. The promotions manual is explicit: if an administrator added the group on the profile, the hourly job will not take it away just because the member no longer matches a promotion’s criteria. Conversely, a promotion that also targets Whitelisted can add people you never interviewed. Do not point a “100 reactions” promotion at the same group you use as a human gate.

Promotions are a ladder, not an interview

Groups & permissions > User group promotions. Add promotion. Title, user groups to add, criteria. If you select no criteria, it never fires. The job is a cron at Tools > Cron entries > User group promotions, hourly. It only processes recently-active members. Quiet accounts wait until they log in. If you need “everyone, including ghosts,” that is Users > Batch update, not a promotion.

Official examples of criteria: registered more than a year, reaction score over 100, has an avatar, posted at least X messages. Those are the right tools for a Member → Regular ladder, a birthday banner, or a “new user” styling group you later remove.

They are the wrong tools for “staff heard this person on voice.” There is no criterion for “thread in forum apply has prefix Approved.” If you try to fake it with “posted at least 1 message” plus “registered 0 days,” you will whitelist everyone who sneezed in General.

Manual promotion (the Manage promoted users button) is a different hammer: you force or forbid a promotion, not a group you also hand out by hand. Prefer the profile’s secondary-group list for whitelist yes/no. Leave promotions for the automatic ladder.

Disable a promotion and it stops adding new people. It does not demote the ones already in. Deleting it also does not unwind memberships. The manual’s undo paths are: delete the dedicated group, batch-remove the group, or change the criteria so nobody matches and wait for active users to be demoted. Read that page before you point a test promotion at Whitelisted.

Permissions to prove before you announce the form

Work the same overlay you use everywhere else. Then prove it with four accounts.

Account	apply	play (private)	What you are proving
Guest	View if you want the queue public; otherwise no	No	Guests cannot lurk the locked lore
Fresh Registered	View + post thread + reply; cannot pick Approved; cannot edit staff_notes	No	The form works; the gate holds
Same account after secondary Whitelisted	View (optional)	View + reply (and post if that is policy)	The group is the key
Moderator	Prefix, edit, delete, see unapproved	View	Staff are not locked out by Private node

If the fresh account can see play, you did not check Private node, or Registered has an explicit View node = Yes you forgot. If the approved account cannot see play, you added the wrong group, you used Never on Registered, or the parent category is hidden from them. Analyze permissions will show which.

Node-specific moderators (moderators menu on the node → add moderator) are how you give a trusted member queue rights without making them a global moderator. They inherit those rights on child nodes. Use that when the FiveM staff should not also sit in the billing forum.

After they are in

The locked forum is now a normal room. Treat it like one. A short description, a first-screen link if the whole site is “apply then play,” and the onboarding work that actually keeps people. A whitelist that dumps approved members into an empty play forum is a locked empty room.

Revoking access is the inverse of step 4: edit the user, remove Whitelisted. They lose View node on the private forum immediately. Leave the Approved thread where it is. It is the record. If you must hide the record, soft-delete it; do not rewrite history by moving every denied thread into a public shame forum.

Banned is not un-whitelisted. A ban is a separate tool. A member can be banned and still sit in Whitelisted until you take the group off. Do both if they are done.

If you later sell the same room, the official A premium content forum walkthrough is this article’s private-node steps plus Users > User customization > User upgrades adding Subscribers under Additional user groups. Do not run a paid upgrade and a human whitelist onto the same group unless “paid or interviewed” is really the rule. Two doors, one group, no audit trail.

When an add-on is the right tool

Stock XenForo will not:

• Add a user to a group when a prefix changes
• Limit View to “this thread’s author + staff”
• Sync a Discord role when you approve the thread
• Query a game server and tick a box that they actually joined
• Show a dedicated application inbox that is not the approval queue or a forum

If any of those is the product, you want an add-on built for 2.3 — including style variations and the SVG icon system — or a small listener on XF\Entity\Thread. Confirm it does not move primary group. Confirm it logs who approved. Confirm you can still do the job if you disable it tomorrow.

This site used to sell a whitelist request plugin. That product is not a requirement to have a queue. It is a reminder that the job is old: a form, a decision, a group. The unglamorous half is prefixes, fields, and a Private node. Buy the automation when staff are already drowning in a queue that works.

FAQ

Can I make applicants fill this in at registration?
You can show custom user fields at registration. Use that for two short facts. A six-question whitelist at signup is how people lie faster and how you store interview answers on the profile forever. Prefer a thread after they have an account.

Can guests apply?
Guests cannot hold a secondary group. They register first. The apply forum is for Registered.

Should each game get its own apply forum?
Only if each game has its own staff and its own questions. Otherwise one forum and a radio field for the game. Extra nodes are extra permission work.

Can I use a suggestion forum so we vote on who gets in?
No. Suggestion threads live in suggestion forums and sort by vote. That is a contest. A whitelist is a staff decision.

Will a promotion on “posted in apply” work?
There is no such criterion in stock promotions. Message count is global. You would whitelist anyone who posted anywhere.

Why did Analyze permissions still say No after I added the group?
Either you edited the wrong user, the parent node is not viewable, or Registered has Never on View node. Or you have not saved. Reload the analysis.

Do I need Resource Manager?
No. XFRM is a catalogue. An application is not a resource. Do not make people file a resource to ask for a group.

What if I already used the listing thread as the application?
Split it. The listing stays a listing. New applications go here. Old hybrid threads get a staff note and a link. Do not migrate by renaming the directory to apply.

Do this afternoon

1. On paper, write the three questions you will actually read. Those are required thread fields. Everything else is optional or staff-only. Age band, not birthday.
2. Groups and permissions > User groups > Add user group: Whitelisted. Defaults. Banner optional. Registered stays primary for everyone.
3. Forums > Nodes: one apply forum (Registered can post) and one play forum. Play: Permissions → Private node → View node = Yes on Whitelisted, Administrative, Moderating.
4. Forums > Thread prefixes: Pending / Interview / Approved / Denied. Applicable forums = apply. Only staff can use the last three. Usage help on Pending says staff will change it.
5. Forums > Custom thread fields: the three questions plus staff_notes. Status block. Applicable forums = apply.
6. Create a dummy Registered account. Post an application. Confirm you cannot see play. Add Whitelisted on User details. Confirm you can. Run Analyze permissions. Then decide, in the forum description, whether the queue is public or held in moderation.

A whitelist that tells the truth with four prefixes and a secondary group will beat a plugin you cannot explain to the next moderator. Ship the truthful queue today. Buy the automatic group flip when the queue is already full.