Okta SSO
Enterprise single sign-on with Okta, with automatic user and role management through SCIM provisioning.
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 Okta account. Okta decides who has access and which role each person holds:
- Single Sign-On (OIDC): users click Continue with SSO and authenticate with Okta. No Automatum passwords.
- SCIM provisioning: Okta creates users in Automatum, assigns their role, updates it when it changes, and removes access when a user is unassigned or deactivated.
- Instant deactivation: when a user is deactivated or unassigned in Okta, their Automatum access stops immediately — even if they are still signed in.
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.
- Okta admin access (you must be able to create an app integration and configure provisioning).
- 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 Okta app integration
In the Okta Admin Console, go to Applications → Applications → Create App Integration.
Select OIDC – OpenID Connect and Web Application, then click Next.
Name it (for example,
Automatum).Under Sign-in redirect URIs, paste 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/idpresponseUnder Assignments, select Limit access to selected groups (or assign later). Click Save.
On the app's General tab, note the Client ID and Client secret.
Note your Okta domain (for example
acme.okta.com— shown in the admin console under your account name).
Step 2: Set up roles in Okta
Automatum reads each user's role from the SCIM roles attribute. Okta has no built-in app roles, so add a role attribute to the app's user profile and map it:
- Go to Directory → Profile Editor → your Automatum app's user profile → Add Attribute.
- Create an attribute (for example
automatumRole) with Enum values. The values must match exactly:
| Display name | Value | Automatum role |
|---|---|---|
| Owner | Owner | Owner |
| Manager | Manager | Manager |
| Editor | Editor | Editor |
| Deal Desk | DealDesk | Deal Desk |
| Co-sell Manager | CosellManager | Co-sell Manager |
| Viewer | Viewer | Viewer |
- Set the attribute per user on their app assignment, or per group with group assignments.
See Roles & Permissions for what each role can do.
One role per user
Give each user exactly one role value. A user with no role, or an unrecognized value, is treated as a Viewer (read-only). Access always fails closed.
Step 3: Submit the configuration in Automatum
- In Automatum, go to Settings → Integrations → Single Sign-On (Owner role required).
- Select Okta as the provider and enter:
- Okta domain — from Step 1 (for example
acme.okta.com) - Client ID — from Step 1
- Client secret — from Step 1
- Email domain(s) — your team's work email domains
- Okta domain — from Step 1 (for example
- Click Save. Automatum provisions your connection in draft mode and shows:
- A SCIM Tenant URL
- A SCIM secret token
Copy the token now
The SCIM token is shown once. Store it somewhere safe. If you lose it, use Rotate token on the SSO card to get a new one (the old one stops working).
Step 4: Configure Okta provisioning (SCIM)
- On the app's General tab, click Edit and set Provisioning to SCIM. Save.
- On the new Provisioning tab, open Integration and enter:
- SCIM connector base URL: the SCIM Tenant URL from Step 3
- Unique identifier field for users:
email - Supported provisioning actions: Push New Users, Push Profile Updates
- Authentication Mode: HTTP Header, with the SCIM token from Step 3 as the Bearer token
- Click Test Connector Configuration, then Save.
- Under Provisioning → To App, enable Create Users, Update User Attributes, and Deactivate Users.
- Still under To App, check the attribute mappings:
userName→ the user's emailroles→ your role attribute from Step 2 (add this mapping if it is missing)
Step 5: Assign users
- On the app's Assignments tab, assign your users or groups.
- Set each user's role attribute (Step 2) on the assignment.
- Okta provisions assigned users to Automatum. Use the app's Provisioning log (or push a single user) to confirm your own user synced.
Step 6: Test sign-in
- Make sure your own user is assigned with the Owner role and has been provisioned.
- Open the Automatum sign-in page in a private browser window.
- Enter your work email and continue with SSO. Sign in with your Okta account.
- You should land in Automatum with your assigned role. On the SSO card, click Test configuration to see what Automatum resolved.
Step 7: Activate
Activation is the switch-over. After it, your domain's users sign in through Okta 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 6).
- At least one provisioned, 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
Everything is managed in Okta:
| To do this | Do this in Okta |
|---|---|
| Add a user | Assign them to the app with a role value |
| Change a role | Change their role attribute on the assignment |
| Remove access | Unassign them from the app, or deactivate the account |
On the Automatum Team page, provisioned users show as managed in Okta and cannot be edited there.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "No provisioned user for this login" | The user has not been provisioned yet | Assign the user in Okta and confirm the push in the provisioning log |
| Sign-in works but the role is Viewer | Missing or misspelled role value | Set exactly one role value from the table in Step 2 |
| "No active membership" | The user was unassigned or deactivated in Okta | Re-assign the user; provisioning reactivates them |
| Activation refused | No test sign-in yet, or no provisioned Owner | Complete Step 6; assign the Owner role and provision |
Provisioning errors mention a missing externalId | The SCIM mapping does not send Okta's user ID | In the To App mappings, map externalId to the Okta user ID |
| "SSO required for this organization" on password login | SSO is active for your organization | Sign in through Okta |
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 and provisioning stop, 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 Google Workspace SSO guide, or Other Identity Providers (Generic OIDC).