BC-0246 · TROUBLESHOOTING
Editorial review 2026-09-27 · Official sources conflict
Friend Cannot Open a Build Playtest
If a particular friend cannot enter an available test, use that person's exact notice and the intended destination to distinguish account access from a general launch failure. A creator's successful session does not prove another account is eligible. Do not request identity documents, borrow accounts or bypass restrictions.
Symptom
An intended recipient cannot enter although the creator or another known participant may have a different outcome.
Immediate action
Collect only the destination context and exact nonsensitive notice from the affected recipient.
Diagnostic branches
- The recipient opened the wrong project or context.
- Correct the supplied destination before making an account diagnosis.
- An explicit restriction is shown.
- Follow the person's legitimate official correction or eligibility path without evasion.
- No restriction appears and loading stops.
- Use launch-stage investigation and leave the account cause unconfirmed.
Least-destructive change
Preserve project and account settings; collect a minimal observation rather than changing identity or audience to force entry.
Retest
- Recipient and creator results remain separate.
- No sensitive identity data or credentials were requested.
- A named restriction is distinguished from an unexplained loading failure.
Escalation
Use official assistance with the recipient's actual notice when needed. The affected person should handle their own private account verification; a creator's public report should not include their identity evidence.
Working notes
Ask the recipient for the visible outcome, not private credentials: did the intended destination open, was a notice shown, or did loading stop without explanation? They can describe a notice without sending a date of birth, identity document or account password. Keep any screenshot limited to the relevant message.
Verify the destination through the real sharing interface if available. If it points to a different project or publication context, correct that mismatch first. Do not attribute a wrong destination to the friend's account. If it is the intended destination, preserve the actual access message rather than replacing it with a guessed age, region or friendship requirement.
Any account correction should use the person's own truthful official account process. Eligibility for using Build, a private test and a published audience are not interchangeable labels. The documentation conflict about private testing remains unresolved, so the existence of instructions alone cannot establish this recipient's access.
If another already invited person has an observation, record it as a comparison only. Do not recruit a large group or create extra accounts to probe a limit. Different outcomes can narrow a support question but do not prove an undocumented allowlist or a defect in the affected account.
Examples
- Privacy-safe request: 'What exact message appears before the game opens? Please omit your personal details.' This collects the restriction evidence without collecting proof of identity.
- Comparison: creator enters; intended recipient reaches an account notice. Record separate outcomes rather than reporting that the game failed to generate.
- Unexplained loading: no specific access notice appears. Keep eligibility unknown and follow the loading boundary instead of assuming the friend's age is responsible.