Access

The Access page controls how people reach this organization: whether they can leave it for another workspace, which e-mail domains join it automatically, how OAuth groups map onto teams, whether members must sign in through an OAuth provider, and whether the organization gets a login page of its own.

Open it from Security → Access in the organization settings.

Info
Organization admins can see and change almost everything on this page. The domain list is the exception: only a platform administrator can add or remove domains, and for an organization admin those rows are read-only.
The Access page: allow users to change organization, domain list, OAuth team attribute and require OAuth

Allow users to change organization

On by default: members can switch to another organization they belong to, or to their personal workspace, and get that scope's configuration. Turn it off to hold members inside this organization, so your configuration always applies.

Domain

Anyone who registers with an e-mail address ending in one of these domains is added to the organization automatically, with no invitation step.

  • Type a domain into the empty row at the bottom of the list and select Add. It is saved straight away and becomes a row of its own.
  • Remove a domain with the red trash button at the end of its row.
  • The empty row stays at the bottom after every addition, so an organization can hold as many domains as it needs.
Warning
Add refuses anything that is not a valid domain: an "Invalid domain" message appears, what you typed stays in the field, and nothing is saved. Correct it and select Add again.

OAuth Team Attribute

The claim in the OAuth provider response that carries the user's group or team. When it is set, users signing in through OAuth are mapped onto the matching team inside this organization instead of only joining the organization itself. Type the claim name and select Change to save it.

Require OAuth

When this toggle is on, members of this organization must authenticate through an OAuth provider — the username and password form is refused for them, even if it is still shown to everyone else on the instance.

Custom Organization Login Page

This gives the organization a sign-in page of its own, on a dedicated URL, showing only the providers you choose. It is the page you hand to the organization's members instead of the shared QAnswer login.

Turn the toggle on to reveal the configuration. Nothing is published until a Login ID is set — the chip next to the heading turns to "Active" once it is.

Login ID

The unique identifier that appears in the page URL. Enter "acme-docs" and the page is served at /org/acme-docs/login; the line below the input shows the full address, with a copy button next to it.

Info
Every other control in this section stays disabled until a Login ID is filled in, because there is no page to configure yet.

What appears on the page

  • Show username & password — keep the e-mail and password form on the page. Turn it off for an organization that signs in exclusively through OAuth.
  • OAuth providers — tick the providers to show. Only providers already configured on the instance Access page are listed, so the sign-in buttons on this page are a subset of the ones on the standard login page.
Custom Organization Login Page section, active, with a login ID, the generated URL and the provider selection

The resulting page

Members opening the dedicated URL get the organization's own page: the username and password form if you left it on, and only the providers you ticked.

The resulting organization login page showing only the configured provider

A "Login using QAnswer" link at the bottom sends anyone who reached the page by mistake back to the standard QAnswer login. There is no Register button — the organization login page is for existing members.

Info
The toggles and the login page settings take effect as soon as you change them. The domain list and the OAuth team attribute are the exceptions: each has its own Add or Change button, and nothing is stored until you press it.