Your community is the group of testers who belong to you rather than to the BetaTesting Panel. This article covers every route a person can take into that community, which of those routes you control, and how to open or close each one.

Teams use this to run a private panel: employees, existing customers, a recruited research group, or a closed beta list. You decide whether anyone who finds your sign-up page can join, whether they need a single-use code you handed out, whether their email address has to be approved in advance, or whether they arrive through your company identity provider. You can also hold new arrivals on a waiting list and admit them yourself.

These are the routes you turn on and off yourself:

People also arrive as a side effect of things you do elsewhere on the platform:

BetaTesting records how every member arrived. In Community, the Tester Source filter splits your members into BetaTesting Panel and Your Own Users.

Registration settings live on the Tester Onboarding page in your company menu. You need full admin access to your company account to open it.

The page is laid out top to bottom as Registration mode, Invite codes, Allowed emails, Welcome Message, and Waitlist Communications. If your plan includes a member cap, a counter at the top shows how much of it you have used, for example "512 of 600 onboarded members".

Everything here depends on having a subdomain. Until you set one, the registration methods stay switched off and you will see the notice "Add a subdomain first so testers have a place to register. These methods stay off until then." Set it under Company Branding, in the Community Landing Page section, in the Subdomain field. Your community then lives at yourcompany.betatesting.com.

The Registration mode section is where you decide how people register. Each method is a switch, and you can turn on either one or both together.

If neither Invite codes nor Email allowlist is on, your community is open: anyone who reaches your landing page can create an account and join. Turning on either one makes registration invitation-only. When both are on, a person gets in by satisfying either one, so a valid code works even if the address is not on your allowlist, and an approved address works without a code.

Switching a method off later does not remove anyone who already joined through it. It only stops new registrations using that route.

Invite codes suit handing out access one person at a time, when you do not know the email addresses in advance. Each code works once.

The table lists every code with a status of Available, Redeemed, or Revoked, and a Redeemed by column showing who used it. The CSV export adds who created each code and the dates it was created, redeemed, or revoked.

A code that is wrong, already used, or revoked gives them "Invitation required. Please check your code or email."

You can save them a step by putting the code in the link. Add a question mark, then inviteCode=, then the code itself to the end of your sign-in URL, and the field is filled in for them. Nothing in the product builds that link for you, so you would compose it yourself.

Click Revoke beside any code that is still available. A code that has already been redeemed cannot be revoked, because the person is already a member. Remove that person from your community instead.

The allowlist suits the opposite situation: you already know exactly which addresses should get in. Only people whose email address you have approved can register.

Either way we tell you how many addresses were added, how many were already there, and how many were not valid email addresses. Use the search box above the list to find an address, and Remove to take one off.

Your CSV should be a single column of email addresses. If a row has more than one column the whole upload is refused and we name the row to fix, so nothing is imported half way.

Someone who tries to register with an address that is not approved sees "This email has not been allowed access. Reach out to us if you think there has been a mistake." If you also have invite codes switched on, they are asked for a code instead, since a code is the other way in. Without a valid one they see "Invitation required. Please check your code or email."

When you import testers from a CSV you can tick Also add these emails to my allowed list during the import, which saves adding them here separately.

The waiting list holds new registrations until you admit them, so you can review who is joining or keep your community at a size you can manage. It is part of the Community Waiting List feature, which is granted separately, so it may not be available on your account.

This section covers the registration setting itself. Your community member cap and the waiting list covers the rest: how the member cap works, how to release people from the list, and how to reword the waiting-list page and the release email.

Under Registration mode, Send new registrations to waiting list has three settings:

When the mode is anything other than Off, a further switch appears: Add to waitlist before registration & onboarding. Turn it on to hold people before they go through onboarding rather than after, so they complete onboarding only once you have accepted them.

The difference is what a new person is asked for. With this switch on, they give only their email address and land straight on your waiting-list page, with no password or profile to fill in until you accept them. With it off, they register and complete onboarding as normal, and are then held on the waiting-list page until you let them in.

You can also hold people you import. The import dialog offers Send to the waiting list, described there as "Holds imported testers on your community's waiting list. They can onboard, but get no access until you invite them from the list."

Your landing page is what people see at your subdomain before they sign up. It carries your heading and text over a hero image, with two buttons: Create an account and Login. Whichever they pick, we work out from their email address which route applies to them, so the same page serves single sign-on, invite codes, the allowlist, and plain sign-up.

You edit the page under Company Branding, and the one-time welcome message new members see just after they join under Tester Onboarding. Both are covered in Branding and customizing your community, along with your subdomain, logos, colors, and terms.

Single sign-on routes your people through your own identity provider, and SCIM provisioning can create their community membership automatically. It is an Enterprise feature, so it may not be available on your account.

SSO is set up from Integrations in your company menu, on the Single Sign-On tab, and it is not fully self-serve: you submit your setup details and our team builds the connection on our side before you can enable it. You need a subdomain before you can begin, because the subdomain anchors which email domains are allowed to sign in and becomes your sign-in URL. Single sign-on overview walks through what to have ready and how the setup runs.

Not every member registers. These routes add people to your community as a result of something else you did.