An owner or admin configures provisioning under Settings, Single sign-on. For the sign-in connection, follow Okta single sign-on.

Prerequisites

An owner or admin account in a Cust organization with access to Single sign-on settings. Provisioning works independently of SSO sign-in; Enable single sign-on can remain off.
An Okta administrator with permission to configure application provisioning.
The Cust Okta integration with provisioning support, or Okta's SCIM 2.0 Test App (Header Auth) for testing while the catalog listing is unavailable.
Verified email domains for the users you will provision. Follow Verify your email domains.
Okta Identity Governance to manage roles through Entitlement Management with the Cust catalog app. The SCIM test app can use attribute-based role mapping instead.

Use the Cust organization and region you want to provision into. SCIM-only setup does not require an OIDC issuer, client ID, or client secret. If you also configure SSO, use that same organization and region.

Supported features

Feature	Behavior in Cust
Create users	Creates organization membership for assigned users, including users who already have a Cust account.
Update user attributes	Updates the sign-in email, names, supported timezone, and assigned role.
Deactivate users	Deactivates organization access, retains the member record, and revokes their Cust sessions and organization API keys.
Reactivate users	Restores organization access when the user is provisioned as active again. Revoked API keys are not restored.
Role management	Sets Admin, Builder, or Member access through Entitlement Management in the catalog app, or attribute mapping in the SCIM test app.
Entitlement Management	Lets Okta discover and assign Cust's three supported roles through governance workflows.

Provisioning does not grant ownership. The Import feature is not supported. Group push and password synchronization are not supported.

Entitlement Management

The Cust catalog app uses Entitlement Management to assign roles. With Okta Identity Governance, you can manage those roles through access requests, reviews, and policies.

Enable Entitlement Management before connecting provisioning. For the Cust app, Okta only allows enabling it while provisioning is off.

On the Cust application's General tab in Okta, enable Entitlement management.
Follow Connect provisioning below.
After the connection is established, allow Okta to discover Cust's Admin, Builder, and Member roles.
Grant the intended role through your Okta governance workflow and confirm the result in Cust.

If provisioning is already connected

Switching provisioning off in Okta deletes its provisioning connection and can remove provisioning data, relationships, and rules. Review Okta's migration considerations before changing an existing setup. Record the existing configuration and assignments before disconnecting, and verify them after reconnecting. Have your current Cust token available, because you will need to enter it again.

In Okta, open Provisioning, then Integration, and turn off Enable API integration.
On the General tab, enable Entitlement management.
Reconnect provisioning by enabling API integration and pasting the Cust token alone into the catalog app's API token field. Test the credentials and save.
Restore Create Users, Update User Attributes, and Deactivate Users under Provisioning, then To App. Confirm role discovery and test an assignment.

If you no longer have the token, generate a replacement in Cust and use it to reconnect. Generating a replacement invalidates the previous token.

Ownership remains managed in Cust. It is never granted or revoked through Okta role mapping or entitlements.

Connect provisioning

If you will manage roles with the Cust catalog app, enable Entitlement Management as described above before enabling API integration.

In Cust, open Settings, then Single sign-on. Under User provisioning (SCIM), select Generate token.
Copy the token when it is shown and store it securely. It is shown only once.
In the Okta application, open Provisioning, then Integration, and enable API integration.
For the Cust catalog integration, paste the token alone into the API token field. Do not add Bearer: Okta adds that prefix automatically.
If you use the SCIM 2.0 Test App (Header Auth), select Other OpenID Connect provider in Cust to view the SCIM base URL. Copy that URL into Okta, use HTTP Header authentication, and enter Bearer <token> as the authorization value.
Test the API credentials in Okta and save the integration.
Under Provisioning, then To App, enable Create Users, Update User Attributes, and Deactivate Users.
Assign a test user and confirm that they appear in the intended Cust organization's members list.

This example shows provisioning before a token has been generated. Generate and copy the token from your own Cust organization.

Replacing a token

Generating a replacement token invalidates the previous token. Update the Okta integration with the replacement before testing provisioning again.

Attribute and role mapping

Use the user's work email as their application username. It must belong to one of the domains verified in Cust's Single sign-on settings.

Cust also accepts the SCIM timezone attribute when your Okta mapping sends a valid IANA timezone, such as Europe/Vilnius or America/New_York. It updates the user's timezone and adjusts their scheduled agents. Omitted or unsupported timezone values leave the existing value unchanged.

Cust catalog app

Assign Admin, Builder, or Member through Entitlement Management. Removing the Role entitlement returns the user to Member.

SCIM test app

For the SCIM 2.0 Test App (Header Auth), configure the SCIM roles attribute in the app profile and map it when you want Okta to set a role:

Role value	Cust role
`ADMIN`	Admin
`BUILDER`	Builder
`MEMBER`	Member

Removing the current role through a role-removal operation returns the user to Member. Sending an empty or unrecognized roles attribute does not reset an existing member's role. Set MEMBER explicitly when downgrading a role through attribute mapping.

Role behavior

New users without an assigned role receive Member access. A Cust member has one role. When Okta supplies multiple supported roles, the most privileged applies: Admin, then Builder, then Member.

For the access each role provides, see Members and roles.

Managing and deactivating users

While provisioning is enabled, users managed by Okta cannot have their role or active status changed in Cust. Make those changes in Okta. Turning off Enable single sign-on does not disable provisioning or unlock these member controls. To stop provisioning, use Disable provisioning in Cust.

Deactivating a user through provisioning marks their membership Deactivated in the connected organization and revokes their active Cust sessions, including sessions in other organizations. Their Cust account and member record are retained. API keys that user created for the connected organization are revoked; reactivation does not restore them. Transfer ownership in Cust before deprovisioning an organization owner.

To verify the lifecycle, use a test member to check creation, a role update, deactivation, and reactivation. Confirm each result in Cust before assigning the rest of your team.

Troubleshooting

Problem	What to check
The API credential test fails	Use the SCIM base URL for the correct region and the current Cust token. For the catalog app, paste the token alone. For the SCIM 2.0 Test App (Header Auth), enter `Bearer <token>`. SSO sign-in does not need to be enabled.
Provisioning rejects the user's email	Verify that email domain in Cust's Single sign-on settings and use the work email as the application username.
Users are not created or updated	Check the Okta app assignment and the Create Users and Update User Attributes options under To App.
A role or active-status change is blocked in Cust	Manage the Okta-provisioned user in Okta while provisioning is enabled.
The role is Member	For the catalog app, check the Admin or Builder entitlement. For the SCIM test app, check that the `roles` mapping includes `ADMIN` or `BUILDER` if elevated access is intended.
Deactivation fails for an owner	Transfer organization ownership in Cust first.
Entitlements are unavailable	Confirm Okta Identity Governance availability. Enable Entitlement management before connecting provisioning. If already connected, follow the reconnection steps.

Contact us

Email support@cust.co with your Cust region, organization name, and the relevant Okta provisioning error. Do not send your provisioning token or client secret.