Organization Access

Manage who can join your organization and how they sign in — verified domains, auto-join, and SAML SSO

For organization admins setting up how their team signs in. Everything here starts with a verified email domain:

• Verify a domain you own, such as company.com.
• Auto-join: add everyone who signs in with an email on that domain, without inviting them one by one.
• SAML single sign-on (SSO): sign in through your identity provider (IdP). Any SAML 2.0 provider works, including Okta, Microsoft Entra ID, and Google Workspace.

All settings are under Organization Settings → Authentication and need an Admin or Owner role (Roles and Permissions).

Domain verification and auto-join are available to every organization. SAML SSO is a plan feature that QA.tech turns on for you. Until then, the SAML configuration section is hidden. Contact QA.tech to enable it.

Setup at a glance

1. Ask QA.tech to enable SAML SSO

   Skip this if you only need auto-join.

2. Verify your email domain

   Add a DNS TXT record. See Verify a domain.

3. Create a SAML app in your identity provider

   Enter QA.tech’s ACS URL and Entity ID, and send the email as the Name ID. See Set up your identity provider.

4. Connect it to QA.tech

   Paste the IdP metadata under the domain and click Enable SSO. See Paste your metadata and enable SSO.

5. Test with one person

   Use Continue with SSO in a private browser window.

6. Choose how people join, then roll out

   Pick auto-join or invites, and plan for existing QA.tech accounts. See Before you roll out.

1. Verify a domain

1. Add the domain

   In Organization Settings → Authentication → Domains, click Add domain and enter your team’s email domain, for example company.com. Public email domains such as gmail.com can’t be claimed.

2. Add the DNS record

   Create this TXT record with your DNS provider:

   Field	Value
   Host	_qatech-verification.<domain>, for example _qatech-verification.company.com
   Type	TXT
   Value	The token shown in QA.tech, starting with qatech-domain-verify=

3. Click Verify domain

   The domain gets a Verified badge. DNS changes can take up to 48 hours, so if it fails right away, try again later.

Subdomains are covered too: verifying company.com covers cloud.company.com. See Subdomains and multiple domains.

2. Set up your identity provider

Expand Identity Provider Setup under SAML configuration in QA.tech for the values your IdP needs:

QA.tech value	What your IdP calls it
Single sign-on URL (ACS URL)	Single sign-on URL, Reply URL, or ACS URL
Audience URI (SP Entity ID)	Audience URI, Identifier, or Entity ID
Service provider metadata URL	Only needed if your IdP can import service provider metadata

Every IdP also needs:

Setting	Value
Name ID format	Email address
Name ID	The user’s email address on your verified domain
First name	Optional. Attribute firstName, givenName, or given_name
Last name	Optional. Attribute lastName, surname, or family_name

QA.tech also accepts the email as an email or mail attribute, and a display name as displayName, name, or fullName. Names fill in the person’s QA.tech profile.

Okta

1. Go to Applications → Create App Integration and choose SAML 2.0.
2. Set Single sign-on URL to the ACS URL and Audience URI (SP Entity ID) to the SP Entity ID.
3. Set Name ID format to EmailAddress and Application username to Email.
4. Optionally, add attribute statements firstName → user.profile.firstName and lastName → user.profile.lastName.
5. On the Assignments tab, assign the people or groups who should have access.
6. On the Sign On tab, copy the Metadata URL for the next section.
7. On the General tab, under App Settings, turn on Do not display application icon to users. That tile starts sign-in from Okta, which QA.tech doesn’t support. Use a Bookmark App instead.

Microsoft Entra ID

1. Go to Enterprise applications → New application → Create your own application, and choose the option for an application not in the gallery.
2. Open Single sign-on and choose SAML.
3. Under Basic SAML Configuration, set Identifier (Entity ID) to the SP Entity ID and Reply URL to the ACS URL. Set Sign on URL to the app link shown under your domain in QA.tech.
4. Under Attributes & Claims, set Unique User Identifier (Name ID) to the Email address format, with a source attribute that holds the email on your verified domain. Use user.mail if user principal names differ from email addresses. The default given name and surname claims already work.
5. Under Users and groups, assign the people or groups who should have access.
6. Under SAML Certificates, copy the App Federation Metadata Url for the next section.

Google Workspace

1. In the Admin console, go to Apps → Web and mobile apps → Add app → Add custom SAML app.
2. On the Google Identity Provider details step, download the IdP metadata. You’ll paste the XML in the next section.
3. Set ACS URL to the ACS URL and Entity ID to the SP Entity ID. Set Start URL to the app link shown under your domain in QA.tech.
4. Set Name ID format to EMAIL and Name ID to Primary email.
5. Optionally, map First name → firstName and Last name → lastName.
6. Under User access, turn the app on for everyone or for the organizational units that should have access.

For other SAML 2.0 providers: create a SAML app, enter the two QA.tech values, send the email as the Name ID, assign users, and copy the metadata.

3. Paste your metadata and enable SSO

1. Paste the metadata

   Under your verified domain in SAML configuration, choose Metadata URL and paste the https URL from your IdP, or choose Metadata XML and paste the file’s contents.

2. Click Enable SSO

   The domain shows SSO Active, and people on it can use Continue with SSO. Existing sign-in methods keep working. If auto-join is On, only SSO sign-ins are added.

3. Test it

   In a private browser window, click Continue with SSO and enter the email of someone assigned to the app who isn’t a QA.tech member yet. Invite them first or turn on auto-join. Testing with your own address? Read Before you roll out first.

Dashboard tile

Point an IdP dashboard tile at the App link shown under the domain, https://app.qa.tech/auth/sso?domain=<your-domain>. It sends the person straight to your IdP.

Identity provider	Where the app link goes
Okta	Create a Bookmark App with the app link as its URL, and assign it to the same people
Microsoft Entra ID	The SAML app’s Sign on URL, so its own tile works
Google Workspace	The SAML app’s Start URL, so its own tile works

Auto-join

Under Auto-join, each verified domain is either:

Setting	What happens
Off (default)	People need an invite. Someone who signs in with SSO without one sees a page asking them to get an invite from an admin.
On	Without SSO, anyone who signs in with an email on the domain is added as a Member. With SSO enabled, On only adds SSO sign-ins. Email, Google, and other methods need an invite.

Auto-join doesn’t need SSO. Without SSO it applies to every sign-in method. Anyone with a mailbox on the domain can join, not only people assigned in your IdP, so turn it on only if everyone on the domain should have access.

Before you roll out

People who already use QA.tech get a second account. An SSO sign-in is a separate account from an existing email or Google account, even when the email address is the same. The new account has none of the old account’s memberships or role.

What that means for existing members:

• Auto-join off: they sign in with SSO and see “Ask Your Admin for an Invite”. You can’t invite them, because their address already belongs to a member.
• Auto-join on: they join as a Member on a new account, next to their old one.

Pick one of these approaches:

• Move everyone at once: turn on auto-join, ask everyone to sign in once with SSO, then go to Organization Settings → Members. Give admins their role back on their new accounts, and remove the old accounts.
• Move people one at a time: remove the person’s old account under Members, then invite them again. They accept by signing in with SSO.

To move the Owner, transfer ownership to their new SSO account first, then remove the old one. Projects, tests, and runs belong to the organization, so removing an old account doesn’t remove them.

Also good to know:

• Roles: people who auto-join become Members. Change roles under Members. QA.tech doesn’t read roles or groups from your IdP.
• Offboarding: removing someone in your IdP stops new SSO sign-ins, but doesn’t remove them from QA.tech or end a session that’s already open. Remove them under Members too. If that was their only organization, they’re signed out. Automatic deprovisioning (SCIM) isn’t supported yet.
• SSO isn’t enforced: email and Google sign-in keep working. With auto-join On, only SSO sign-ins are added.
• MFA: if your organization requires MFA, people who sign in through your SAML connection aren’t asked to set up a QA.tech authenticator app. Enforce MFA in your IdP instead. Every other sign-in method still needs a QA.tech authenticator app.

How your team signs in

Send this to your team once SSO is active:

1. Open QA.tech and choose Continue with SSO

   Or click the QA.tech tile on your identity provider dashboard, if your admin added one.

2. Enter your work email

   QA.tech sends you to your company’s sign-in page.

3. Sign in

   You’re sent back to QA.tech, signed in.

Managing SSO

Updating metadata. Click Update Metadata on an active domain, for example after your IdP rotates its signing certificate. Metadata from the same IdP app updates the connection in place without affecting anyone.

Metadata from a different IdP app (a different entity ID) replaces the connection after you confirm. Everyone using SSO is signed out and gets a new account on their next sign-in. Handle their memberships as in Before you roll out. If the new metadata is rejected, the current connection stays as it was.

Disabling SSO. Choose Disable SSO from the domain’s menu, or remove the domain. Sign-in through your IdP stops. If no other domain uses the connection, everyone signed in through it is signed out, though an already-issued access token works until it expires, usually within an hour.

Subdomains and multiple domains

• Subdomains are covered automatically. Verifying company.com covers cloud.company.com, and SSO users on the subdomain sign in through the company.com connection.
• Add a subdomain only when it needs different settings. The most specific verified domain wins: with cloud.company.com verified and auto-join off, people on it need an invite even if company.com has auto-join on. They still sign in through the company.com SSO connection unless the subdomain has its own.
• If another organization has verified one of your subdomains, people on that subdomain belong to that organization, and your SSO connection can’t sign them into yours.
• Another domain you own can use the same IdP app. When you enable SSO for company.io with the app already connected to company.com in the same organization, QA.tech adds company.io to that connection. Disabling SSO on one of them leaves the other in place. An app already connected to a different organization still can’t be reused.

Troubleshooting

The SAML configuration section isn’t visible

• SAML SSO hasn’t been enabled for your organization yet. Contact QA.tech.
• You need to be an organization Admin or Owner.

Domain won’t verify

• The TXT record host must be exactly _qatech-verification.<domain>. Common mistakes are leaving out the _qatech-verification. prefix, or the DNS provider adding your domain a second time (_qatech-verification.company.com.company.com).
• The value must match the token in QA.tech exactly, including qatech-domain-verify=.
• DNS can take up to 48 hours. Wait and click Verify domain again.

“The identity provider metadata was rejected”

• The metadata URL must be public and use https. If your IdP’s metadata isn’t publicly reachable, paste the XML instead.
• If you pasted XML, make sure you copied the whole file.

“This identity provider app is already connected to another domain”

• That app is already connected to a domain in a different organization. Each app can only belong to one organization. Subdomains, and other domains in your own organization, can share the app.

“This domain is still assigned to another SSO connection”

• An earlier connection for the domain wasn’t fully removed. Contact QA.tech support to release it.

“Failed to disable SSO” or “Failed to remove domain”

• QA.tech couldn’t remove the connection, so SSO is still active for the domain. Try again. If it keeps failing, contact QA.tech support.

“No SSO provider configured for this domain” at sign-in

• The email’s domain, or a parent domain, doesn’t have SSO Active. Check Organization Settings → Authentication.
• The person may have entered a personal email instead of their work email.

The IdP shows an error before returning to QA.tech

• The person may not be assigned to the app in your IdP.
• Check that the ACS URL and Entity ID in your IdP match QA.tech exactly.
• If they clicked the Okta SAML app’s own tile, hide that tile and use a Bookmark App. See Dashboard tile.

“Wrong Account for This SSO Connection” after signing in

• Your IdP sent an email address that isn’t on the verified domain. Check the Name ID setting in your IdP. In Entra ID, a user principal name that differs from the email address is a common cause.

“Ask Your Admin for an Invite” after signing in

• Auto-join is off for the domain. Invite the person, or turn auto-join on.
• If the person was already a member, they now have a second account. See Before you roll out.

Need help? Contact QA.tech support with your domain and identity provider.