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

Prerequisites

A Cust organization with single sign-on configured and enabled, and an owner or admin account. Provisioning credentials will not authenticate while SSO is disabled.
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 if you want to use Entitlement Management. Ordinary role mapping does not require the entitlement-management setup below.

Use the same Cust organization and region as your SSO connection.

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 supported profile fields and assigned roles.
Deactivate users	Removes the user from the organization and revokes their Cust sessions.
Reactivate users	Restores organization membership when the user is provisioned as active again.
Role mapping	Sets Admin, Builder, or Member access.
Entitlement Management	Lets Okta discover and assign Cust's three supported roles through governance workflows.

Provisioning does not grant ownership. Group push and password synchronization are not supported.

Connect provisioning

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, enter Bearer <token> in the API token field, replacing <token> with your token. The SCIM base URL is filled from the integration's tenant settings.
If you use the SCIM 2.0 Test App (Header Auth) with manual OIDC setup, 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 verified domains on your Cust SSO configuration.

Map the SCIM roles attribute when you want Okta to set a role:

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

New users without a mapped 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.

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

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

Entitlement Management

With Okta Identity Governance, you can manage Cust roles through access requests, reviews, and policies.

Configure provisioning on the Cust Okta integration.
On the application's General tab, enable Entitlement management.
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.

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

Managing and removing users

While provisioning is enabled, users managed by Okta cannot have their role changed or be removed in Cust. Make those changes in Okta.

Deactivating a user through provisioning removes their membership from the connected organization and revokes their active Cust sessions. Their Cust account is retained. 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	Confirm SSO is enabled in Cust. Use the SCIM base URL for the correct region and the current token, including the `Bearer` prefix.
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 change or removal is blocked in Cust	Manage the Okta-provisioned user in Okta while provisioning is enabled.
The role is Member	Check that the mapping or entitlement 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 and enable Entitlement management on the supported Cust integration.

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.