Google Workspace SSO
Enterprise single sign-on with Google Workspace. Your team signs in with their Google work account; roles are managed on the Automatum Team page.
Enterprise tier
SSO is part of the Automatum Enterprise plan. Contact your account manager to enable it for your organization.
Overview
With SSO enabled, your team signs in to Automatum with their Google Workspace account:
- Single Sign-On (OIDC): users click Continue with SSO and authenticate with Google. No Automatum passwords.
- Automatic first sign-in: a new user is created in Automatum on their first sign-in, with the Viewer role. An existing Automatum user keeps their current role.
- Domain restriction: only Workspace accounts on your organization's registered email domains can sign in. Consumer
@gmail.comaccounts are rejected.
Roles are managed in Automatum, not in Google. Google Workspace has no SCIM provisioning for custom apps, so it cannot push users or roles. Assign and change roles on the Automatum Team page, as you do today.
Removal is not automatic
Unlike Entra ID or Okta with SCIM, suspending a user in Google does not deactivate them in Automatum. To remove access, act in both places — see Managing users after setup.
Safe setup
Setup runs in draft mode. While you configure and test, nothing changes for your team. Password sign-in is switched off only when you activate, and activation requires a successful test sign-in first. You cannot lock yourself out.
Prerequisites
- Automatum Enterprise plan with SSO enabled.
- An Automatum account with the Owner role.
- Access to the Google Cloud Console for your Workspace organization (you must be able to create OAuth credentials).
- Your team's work email domain. At least one existing Automatum user in your organization must have an email on that domain.
Step 1: Create the OAuth client in Google Cloud
In the Google Cloud Console, create a project (or select an existing one) in your Workspace organization.
Go to APIs & Services → OAuth consent screen. Set User type to Internal and complete the required fields.
Go to APIs & Services → Credentials → Create Credentials → OAuth client ID.
Set Application type to Web application and name it (for example,
Automatum).Under Authorized redirect URIs, add the redirect URI shown on your Automatum SSO card (Settings → Integrations → Single Sign-On). It has this shape:
https://<automatum-auth-domain>.amazoncognito.com/oauth2/idpresponseClick Create. Copy the Client ID and Client secret.
Internal consent screen
The Internal user type limits the app to accounts in your Workspace organization on Google's side. Automatum also enforces your registered email domains, so both layers must match.
Step 2: Submit the configuration in Automatum
- In Automatum, go to Settings → Integrations → Single Sign-On (Owner role required).
- Select Google Workspace as the provider and enter:
- Client ID — from Step 1
- Client secret — from Step 1
- Email domain(s) — your team's work email domains
- Click Save. Automatum provisions your connection in draft mode.
An email domain can belong to only one Automatum organization. If your domain is already claimed, contact support.
There is no SCIM URL or token for Google Workspace — there is nothing to configure on the Google side beyond Step 1.
Step 3: Test sign-in
- Open the Automatum sign-in page in a private browser window.
- Enter your work email and click Continue with SSO.
- Sign in with your Google Workspace account. You should land in Automatum with your existing role.
- Back on the SSO card, click Test configuration to see what Automatum resolved: your identity, your membership, and your role.
Step 4: Activate
Activation is the switch-over. After it, your domain's users sign in through Google and password sign-in is turned off for your organization.
On the SSO card, click Activate. Automatum checks two things first:
- At least one federated sign-in has completed (Step 3).
- At least one active user holds the Owner role.
If either check fails, activation is refused with the reason. Until you activate, nothing changes for your team.
Managing users after setup
Sign-in is managed in Google; roles and access are managed in Automatum:
| To do this | Do this |
|---|---|
| Add a user | Nothing to configure — they sign in with their Workspace account and get the Viewer role |
| Change a role | Change it on the Automatum Team page (Owner or Manager) |
| Remove access | Suspend or delete the user in Google Workspace and deactivate them on the Automatum Team page |
Suspending the Google account blocks new sign-ins. Deactivating the user in Automatum cuts access immediately, including open sessions. Do both — neither one alone is complete.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "Email domain not allowed" | The account is a consumer @gmail.com account, or its domain is not registered | Sign in with a Workspace account on a registered domain; an Owner can add domains on the SSO card |
| Google shows an access error before Automatum | The consent screen is Internal and the account is outside your Workspace organization | Use an account in your organization, or check the consent screen settings |
| Sign-in fails with an unverified email | Google did not report the email as verified | Verify the account's email in Google Workspace |
| New user has the wrong role | First sign-in always creates a Viewer | Assign the correct role on the Automatum Team page |
| Activation refused | No test sign-in yet, or no active Owner | Complete Step 3; confirm an active user holds the Owner role |
| "SSO required for this organization" on password login | SSO is active for your organization | Sign in with Continue with SSO |
| "redirect_uri_mismatch" from Google | The redirect URI in Google does not match the SSO card | Copy the exact URI from the SSO card into the OAuth client (Step 1) |
Use Test configuration on the SSO card to see exactly what Automatum received for your session.
Turning SSO off
An Owner can remove the SSO configuration from the SSO card. Federated sign-in stops, and your email domains are released. User accounts are kept; contact support to restore password access for your team.
Using another provider?
See the Microsoft Entra ID SSO guide, the Okta SSO guide, or Other Identity Providers (Generic OIDC).