Skip to content

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

  1. In the Okta Admin Console, go to ApplicationsApplicationsCreate App Integration.

  2. Select OIDC – OpenID Connect and Web Application, then click Next.

  3. Name it (for example, Automatum).

  4. Under Sign-in redirect URIs, paste the redirect URI shown on your Automatum SSO card (SettingsIntegrationsSingle Sign-On). It has this shape:

    https://<automatum-auth-domain>.amazoncognito.com/oauth2/idpresponse
  5. Under Assignments, select Limit access to selected groups (or assign later). Click Save.

  6. On the app's General tab, note the Client ID and Client secret.

  7. 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:

  1. Go to DirectoryProfile Editor → your Automatum app's user profile → Add Attribute.
  2. Create an attribute (for example automatumRole) with Enum values. The values must match exactly:
Display nameValueAutomatum role
OwnerOwnerOwner
ManagerManagerManager
EditorEditorEditor
Deal DeskDealDeskDeal Desk
Co-sell ManagerCosellManagerCo-sell Manager
ViewerViewerViewer
  1. 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

  1. In Automatum, go to SettingsIntegrationsSingle Sign-On (Owner role required).
  2. 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
  3. 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)

  1. On the app's General tab, click Edit and set Provisioning to SCIM. Save.
  2. 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
  3. Click Test Connector Configuration, then Save.
  4. Under ProvisioningTo App, enable Create Users, Update User Attributes, and Deactivate Users.
  5. Still under To App, check the attribute mappings:
    • userName → the user's email
    • roles → your role attribute from Step 2 (add this mapping if it is missing)

Step 5: Assign users

  1. On the app's Assignments tab, assign your users or groups.
  2. Set each user's role attribute (Step 2) on the assignment.
  3. 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

  1. Make sure your own user is assigned with the Owner role and has been provisioned.
  2. Open the Automatum sign-in page in a private browser window.
  3. Enter your work email and continue with SSO. Sign in with your Okta account.
  4. 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 thisDo this in Okta
Add a userAssign them to the app with a role value
Change a roleChange their role attribute on the assignment
Remove accessUnassign 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

SymptomLikely causeFix
"No provisioned user for this login"The user has not been provisioned yetAssign the user in Okta and confirm the push in the provisioning log
Sign-in works but the role is ViewerMissing or misspelled role valueSet exactly one role value from the table in Step 2
"No active membership"The user was unassigned or deactivated in OktaRe-assign the user; provisioning reactivates them
Activation refusedNo test sign-in yet, or no provisioned OwnerComplete Step 6; assign the Owner role and provision
Provisioning errors mention a missing externalIdThe SCIM mapping does not send Okta's user IDIn the To App mappings, map externalId to the Okta user ID
"SSO required for this organization" on password loginSSO is active for your organizationSign 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.

Automatum GTM Platform