Skip to content
Support Portal
  • There are no suggestions because the search field is empty.

SCIM User Provisioning with Okta

Connect Okta to AlertOps with SCIM 2.0 so users are created, updated and deactivated in AlertOps automatically when you assign or remove them in Okta.

Overview

Relevant for Okta administrators and AlertOps App Admins setting up user provisioning

SCIM (System for Cross-domain Identity Management) lets Okta create, update and deactivate AlertOps users for you. Once it is set up, user lifecycle is driven from Okta: assign someone to the AlertOps app in Okta and they get an AlertOps user; change their details in Okta and AlertOps follows; remove them from the app and their AlertOps user is deactivated.

Key benefits:

  • Automatic onboarding — new users get an AlertOps account as soon as they are assigned the app in Okta.
  • Automatic offboarding — users removed in Okta are deactivated in AlertOps, so access is not left behind.
  • Consistent profiles — name, email and role stay in sync with Okta.

AlertOps supports SCIM provisioning with Okta and Microsoft Entra ID. This article covers Okta. For Entra ID, see SCIM User Provisioning with Microsoft Entra ID.

Users only

SCIM provisioning in AlertOps manages users. Okta groups are not pushed to AlertOps as groups — you can still assign an Okta group to the app to provision all of its members as users.

Before You Begin

Relevant for Anyone preparing the setup

  • Okta administrator access (to add an app and configure provisioning).
  • An AlertOps account with SCIM enabled.
  • Your AlertOps SCIM token and base URL (see below).

Get Your SCIM Token

SCIM tokens are not yet available in the AlertOps UI. To get a token for your account, contact support@alertops.com and include your AlertOps subdomain.

Keep the token secret

The SCIM token can create, change and remove users in your AlertOps account. Store it only in Okta and do not share it in tickets, chat or email threads.

Connection Details

Setting

Value

SCIM base URL

https://api.alertops.com/api/v2/scim/v2

Authentication

Bearer token (your SCIM token)

Supported resource

Users

Supported Roles

Relevant for Admins deciding which AlertOps role users should get

Each provisioned user gets one AlertOps role. The role value Okta sends must match the name of a role in your AlertOps account exactly (for example Basic or App Admin). Custom roles created in your account can be used too.

  • If no role is sent, the user is created with the Basic role.
  • If the role name doesn't exist in your account, AlertOps rejects the request and Okta shows the error Invalid Role.

Most organizations provision everyone as Basic and grant elevated roles to a small number of users. See Step 4 for how to set the role in Okta.

Step 1 — Add the SCIM App in Okta

Relevant for Okta administrators

  1. In the Okta Admin Console, go to Applications > Applications and click Browse App Catalog.
  2. Search for SCIM 2.0 Test App (Header Auth) and click Add Integration.
  3. Enter an Application label such as AlertOps, click Next, then Done.

Step 2 — Connect Okta to AlertOps

Relevant for Okta administrators

  1. Open the app and go to the Provisioning tab.
  2. Click Configure API Integration and tick Enable API integration.
  3. Fill in the fields below, click Test API Credentials, and when the test succeeds click Save.

Field

Value

Base URL

https://api.alertops.com/api/v2/scim/v2

API Token

Your AlertOps SCIM token

Import Groups

Unticked (AlertOps SCIM manages users only)

Step 3 — Turn On Provisioning to AlertOps

Relevant for Okta administrators

  1. On the Provisioning tab, select To App and click Edit.
  2. Enable the options below and click Save.

Option

Setting

Create Users

Enabled

Update User Attributes

Enabled

Deactivate Users

Enabled

Sync Password

Disabled (not supported)

Step 4 — Set Up the AlertOps Role Attribute

Relevant for Okta administrators — required, do not skip

The Okta app template includes a default roles attribute that stores roles as a list of text values. AlertOps returns roles as objects, so Okta can't save the response with the default attribute. Replace it with a single AlertOps role attribute.

If you skip this step

The AlertOps user is created, but Okta marks the assignment as failed with Invalid value data type on the roles property. Okta then can't link to the AlertOps user, so later updates and deactivation for that user are not sent.
  1. Go to Directory > Profile Editor and open the profile for your AlertOps app (for example AlertOps User).
  2. Find the attribute with variable name roles and delete it.
  3. Click Add Attribute and enter the values below, then click Save.

Field

Value

Data type

string

Display name

AlertOps role

Variable name

aoRole

External name

roles.^[type=='alertopsrole'].value

External namespace

urn:ietf:params:scim:schemas:core:2.0:User

Enum (optional)

Define a list of your AlertOps role names if you want admins to pick from a drop-down.

Step 5 — Map Attributes

Relevant for Okta administrators

  1. In the Profile Editor for the AlertOps app, click Mappings and select the Okta User to AlertOps tab.
  2. Set the mappings below and click Save Mappings. When Okta asks whether to apply the change to existing users, choose Apply updates if users are already assigned.

AlertOps attribute

Okta value

userName

Okta username (set on the Sign On tab; use an email address)

givenName / familyName

user.firstName / user.lastName (default)

email

user.email (default)

userType

"Standard"

locale

"en-US" (or user.locale if it is set for all users)

aoRole

"Basic" — or an Okta expression that returns an AlertOps role name

employeeNumber, costCenter, organization, division, department, managerValue, managerDisplayName

Leave empty (not used by AlertOps)

Roles come from the mapping

Because the mapping is applied on create and update, Okta overwrites a role typed directly on a single user's assignment. To give different users different roles, use an Okta expression in the aoRole mapping (for example based on a user attribute or group membership).

Step 6 — Assign Users and Verify

Relevant for Okta administrators rolling out provisioning

  1. Go to the app's Assignments tab and click Assign > Assign to People. Start with one test user.
  2. Click Assign, check the values, then click Save and Go Back and Done.
  3. Confirm the user appears in AlertOps under Users with the correct name, email and role.
  4. Change the user's last name in Okta and confirm AlertOps updates.
  5. Remove the user from the app in Okta and confirm the AlertOps user is deactivated.
  6. When all checks pass, assign the remaining people or groups.

Okta provisions changes immediately; they usually appear in AlertOps within a few seconds.

How Deprovisioning Works

Relevant for Admins planning offboarding

Action in Okta

Result in AlertOps

Remove the user from the app (directly or by removing them from an assigned group)

User is deactivated

Deactivate the user in Okta

User is deactivated

Assign the user to the app again

The same AlertOps user is reactivated (no duplicate is created)

Delete the user in Okta

No further change — Okta deactivates before deleting and never sends a delete. The AlertOps user stays inactive.

Inactive users still count toward your user limit

Deactivated users remain in AlertOps and count toward the number of users on your plan. To free up space, delete inactive users in AlertOps.

Supported User Attributes

Relevant for Admins customizing mappings

SCIM attribute

Description

userName

Required. The AlertOps username — use the user's email address. Must be unique in your account.

name.givenName / name.familyName

First and last name.

emails (type work)

Work email. AlertOps adds it as the user's email contact method.

roles

The user's AlertOps role, returned as {"value": "Basic", "type": "alertopsrole", "primary": true}. Defaults to Basic.

userType

User type, normally Standard.

locale

User locale, for example en-US.

timezone

User time zone as shown in AlertOps.

active

false deactivates the user; true reactivates them.

externalId

The Okta user ID, stored to link the two accounts.

Troubleshooting

Relevant for Anyone debugging provisioning

Okta records every provisioning action. Check Dashboard > Tasks for failed assignments (you can retry them there) and Reports > System Log for the full error message.

Test API Credentials Fails

  • Invalid API Key / 401 — the token is wrong or incomplete. Paste it again without spaces.
  • SCIM is not enabled for this account / 403 — SCIM isn't turned on for your AlertOps account. Contact support@alertops.com.
  • Check the Base URL is exactly https://api.alertops.com/api/v2/scim/v2.

Assignment Fails With "Invalid value data type" on roles

  • The default roles attribute is still in the app profile. Complete Step 4, then retry the failed assignment from Dashboard > Tasks.

"You have reached the maximum purchased users for your account"

  • Your AlertOps account has reached its user limit. Inactive users count toward the limit.
  • Delete users you no longer need in AlertOps, or contact support@alertops.com to increase your limit, then retry the assignment from Dashboard > Tasks.

"Invalid Role"

  • The aoRole value doesn't match a role in your AlertOps account. Role names must match exactly, including spaces and capitals.

User Not Updated or Not Deactivated in AlertOps

  • Check Dashboard > Tasks for a failed task for that user and retry it.
  • Confirm Update User Attributes and Deactivate Users are enabled in Step 3.
  • If the user's assignment shows an error from creation, fix that first — Okta only sends updates for users it has linked successfully.

"UserName already exists"

  • A user with the same username already exists in AlertOps. Okta normally links to the existing user; if it doesn't, contact support@alertops.com.

Need Help?

Contact support@alertops.com for your SCIM token or help with provisioning.