--- title: "Sign-up settings for members and guests" description: "Control who can create an account without an invitation, which sign-up methods are available, and which email domains you accept." category: administration-security section: users-and-access tags: [admin] type: Tutorial lastUpdated: 2026-08-06 locale: en canonical: https://support.talkspirit.com/en/administration-security/members-and-guests-settings --- # Sign-up settings for members and guests ## Sign-up settings for members and guests Everything that decides whether someone can create an account **without being invited** lives on one screen: **Administration > Authentication**, on the **Sign-up settings** tab. There you choose whether self-registration is open, restricted to certain email domains, or switched off, and which sign-up methods people may use. You need administrator rights. Guests are not configured here: a guest is created by inviting one, and what a guest can see is decided by the access scope you pick on that invitation. There is no organisation-wide setting that turns guest invitations on or off. ## Where do I find these settings? 1. Open **Administration**. 2. Under **Security**, click **Authentication**. 3. Open the **Sign-up settings** tab. ![The Sign-up settings tab in Administration, showing the Sign-up access choices, the Allowed domains list and the Sign-up methods switches.](/images/administration-security/members-and-guests-settings/01-sign-up-settings.png) ## How do I control who can create an account? Under **Sign-up access**, pick one of three options: - **Open**: anyone can sign up. - **Domain restricted**: only people whose email address matches a domain you list can sign up. - **Disabled**: no self-registration. People join only when you invite them. Choosing **Disabled** asks you to confirm. Existing accounts keep their access, and you can switch sign-ups back on at any time. Most organisations that invite people one by one want **Disabled**. Choose **Domain restricted** when you want colleagues on your own email domain to join by themselves without asking you first. ## How do I set the allowed domains? The **Allowed domains** list appears only when **Sign-up access** is set to **Domain restricted**. 1. Type a domain in the field, in the form `@example.com`. The leading `@` is required and the entry is rejected without it. 2. Click **Add**. 3. Repeat for each domain you accept. You can list up to 100. Remove a domain with the cross beside it. Switching **Sign-up access** to **Open** or **Disabled** clears this list. If you go back to **Domain restricted** later, you will have to enter your domains again, so note them somewhere first. ⚠️ **Warning:** this list does more than filter sign-ups. It is also the allowlist that authorises automatic account creation through single sign-on: a person who authenticates with your identity provider and whose address matches one of these domains gets an account created on the spot, with no invitation and no approval step. Add a domain only when you are willing for everyone at that domain to be able to join unattended. Two more things worth knowing before you rely on this list: - Each SSO provider has its own **Allowed email domains** field on the **SSO Providers** tab. A match there also authorises automatic account creation, independently of the list on this tab. - If the **Allowed domains** list is empty and your organisation has exactly one authentication provider enabled, and that provider is SAML or OpenID, automatic account creation through it is still allowed. Setting **Sign-up access** to **Disabled** does not close that route. ## How do I choose the sign-up methods? Under **Sign-up methods**, two switches decide how an account can be created and used: - **Email and password**: people sign up and sign in with their email address and a password. - **Unique identifier (UID)**: people sign up and sign in with an identifier instead of an email address. Turn this on before you invite anyone without an email address. See [Adding users without an email address](/administration-security/users-without-email). Turning either one off asks you to confirm, and you type the word `disable` to go through with it. Talkspirit blocks the change outright when it would be the last way in: if the method you are switching off is the only one active and no SSO provider is enabled, the confirmation button stays greyed out, because the change would lock every account out, including yours. ## Can members invite people, rather than administrators? That setting is not here. It lives on **Administration > Invitations**, on the **Settings** tab, as **Allow members to invite new members**, with **Restrict to allowed domains** limiting members to the domains you listed above. Administrators are never bound by that restriction and can invite any address. One caveat to set expectations before you switch it on: the invite controls are administrator-only whatever this setting says. A member who has the permission reaches their invite control in the classic interface. See [Inviting new users, members, or guests](/administration-security/inviting-new-users-members-or-guests). ## Are there settings specific to guests? No. In the new interface there is no organisation-wide switch for guest invitations and no guest-specific sign-up rule. What a guest can reach is decided one invitation at a time, by the **Access scope** you choose when you invite them: - **See the holarchy** - **Access 1 group** - **Access more than 1 group** For what each of those means, and what a guest can and cannot do afterwards, see [Guest users](/administration-security/guest-users). For the difference between an administrator, a member and a guest account, see [User Roles and Permissions](/administration-security/user-roles). ## What's next? - [Inviting new users, members, or guests](/administration-security/inviting-new-users-members-or-guests) - [Managing email invitations for new members](/administration-security/manage-email-invitations-for-new-members) - [Configuring SAML Authentication](/administration-security/saml-authentication) - [Password Security Policy](/administration-security/password-security-policy)