Skip to main content
Use Okta Lifecycle Management to create, update, deactivate, and reactivate OpenWork members. Okta groups can also become SCIM-managed OpenWork teams.

​
Before you start

You need:
  • A working and domain-verified Okta SAML SSO connection.
  • An OpenWork owner, or a member who can manage security configuration.
  • An Okta administrator who can configure provisioning for the SAML app.
  • An Okta plan that supports the provisioning and group-push features you intend to use.
Keep OpenWork SSO enforcement off until both SAML and a narrowly scoped SCIM test pass. Make sure at least one OpenWork owner can sign in through Okta.

​
1. Create the OpenWork SCIM connector

In OpenWork, select the organization, then open Settings → SCIM. Confirm the page reports that SAML/SSO is active, then:
  1. Select Create connector.
  2. Copy the SCIM base URL.
  3. Copy the bearer token immediately. OpenWork displays the full token only after creating or rotating the connector.
  4. Leave Create teams from SCIM groups off until user provisioning works.
Treat the bearer token like a password. Do not put it in tickets, screenshots, logs, or documentation. Rotating it invalidates the previous token, so update Okta during the same maintenance window.
Use the base URL OpenWork displays. In a split-host Helm deployment it may use the web auth origin even when a separate Den API origin also exists. Do not rewrite the hostname.

​
2. Enable SCIM on the Okta application

Use the same Okta application as SAML SSO:
  1. Open Applications → Applications → OpenWork.
  2. Open General and edit App Settings.
  3. Enable SCIM under Provisioning, then save.
  4. Open the new Provisioning tab.
  5. Select Configure API Integration.
  6. Enable API Integration.
Enter: Select Test API Credentials. Save only after Okta reports a successful connection.

​
3. Configure provisioning to OpenWork

Open Provisioning → To App, then enable:
  • Create Users
  • Update User Attributes
  • Deactivate Users
Do not enable password synchronization. SCIM creates federated membership; it does not create an OpenWork password credential. Review the attribute mappings. At minimum, keep these identity values aligned: The SAML NameID and SCIM userName must identify the same person. A mismatch can create a duplicate OpenWork member instead of linking SSO and SCIM.

​
4. Provision one assigned user

Start with the user already assigned during the SAML test:
  1. Open the Okta application’s Assignments tab.
  2. Confirm the test user is assigned and their application username is the same email used for SAML NameID and SCIM userName.
  3. Open the assignment’s provisioning status or Okta System Log.
  4. Confirm Okta’s lookup and create or update operations succeed.
  5. In OpenWork, open Members and verify the same member appears without a second password-backed account.
Do not broaden assignments until the test user’s create, update, deactivate, and reactivate lifecycle works.

​
5. Verify the user lifecycle

For the assigned test user, verify:
  1. Changing the profile name in Okta updates the OpenWork member.
  2. Unassigning or deactivating the user removes active organization access.
  3. The user cannot regain access through password sign-up while SCIM marks the identity inactive.
  4. Reactivating and reassigning the user restores the same OpenWork identity.
  5. An unrelated OpenWork member remains unchanged throughout the test.
OpenWork retains a disconnected member record for organization history. The global user is deleted only after their final active organization membership is removed.

​
6. Push Okta groups as OpenWork teams

After user provisioning works:
  1. In OpenWork Settings → SCIM, enable Create teams from SCIM groups.
  2. In Okta, open the application’s Push Groups tab.
  3. Select Push Groups and choose a small test group by name or rule.
  4. Confirm Okta creates the group and pushes its current membership.
  5. In OpenWork, open Members → Teams and verify a team labeled Managed by SCIM appears with the expected members.
  6. Add and remove one member in Okta and verify the OpenWork team follows.
Manage pushed groups in Okta, not in OpenWork. Manually created OpenWork teams remain independent.

​
7. Expand scope and enforce SSO

After the lifecycle and group tests pass:
  1. Assign the intended Okta users and groups to the application.
  2. Review Okta provisioning events for failures.
  3. Review OpenWork’s SCIM health and unresolved-failure count.
  4. Confirm at least one owner has working Okta SAML access.
  5. Only then consider enabling Require SSO for this organization.

​
Troubleshooting

For member and team behavior after provisioning, see Members and RBAC.