How to Design a FiveM Whitelist Application

This guide covers the application and review process. For ACE, identifiers, Discord roles and server enforcement, use the separate technical FiveM whitelist guide.

Define what the whitelist selects for

Choose observable criteria: rule comprehension, roleplay judgement, communication and availability for the community's play style. Avoid vague questions that reward long answers rather than good decisions.

A focused application

• Character concept in a few sentences
• One or two scenario questions tied to actual server rules
• Timezone and realistic play availability
• Discord and required game identifier
• Show the privacy and retention notice before submission

Do not collect real names, government IDs or other sensitive data that the server does not need.

Separate the privacy notice from consent

Where GDPR applies, choose and document a lawful basis for each use of applicant data before collecting it. A checkbox confirming that someone has read the privacy notice is an acknowledgement, not consent to every use of their data and not a lawful basis by itself.

If you rely on consent for an optional use, describe that purpose separately and use an unticked choice. Applicants must be able to refuse and withdraw consent easily without penalties. Do not make unrelated optional processing a condition of joining, or assume consent is the appropriate basis for processing necessary to review an application.

Privacy source checked on 10 October 2026: EDPB guidance on processing personal data lawfully.

Create a scoring rubric

Criterion	Evidence	Reject when
Rules	Explains the rule in their own words	Answer proposes prohibited behaviour
Scenario judgement	Chooses a proportionate RP response	Uses meta information or breaks character without reason
Communication	Clear enough for staff to assess	Harassment, evasion or copied answers

Use the same rubric for every applicant. Record a short reason for the decision so appeals can be reviewed consistently.

Review workflow

1. Publish expected review time and queue status.
2. Assign applications to reviewers without exposing unnecessary personal data.
3. Escalate borderline cases instead of changing the rubric mid-review.
4. Send acceptance or rejection with the next permitted step.
5. Delete rejected application data after the stated retention period.

Appeals and reapplications

Define a waiting period and one appeal channel. An appeal should correct a review error, not restart the entire application in private messages. Track repeat attempts to prevent reviewer shopping.

Measure quality

Track time to decision, no-show rate, early rule violations and reviewer agreement. If strong applicants abandon the queue, shorten it. If accepted players repeatedly misunderstand one rule, rewrite that question or onboarding step.