Enabling Okta SCIM 2.0 Group Push Provisioning to a SaaS Application

What you're trying to achieve

You want Okta to automatically create, update, and deactivate users in a SaaS application, and you want Okta group membership to appear as groups (or roles/teams) in that app without anyone touching the target admin console. SCIM 2.0 handles the user lifecycle; group push is the Okta-specific mechanism that replicates Okta groups and their memberships over the same SCIM connection.

The useful takeaway up front: user provisioning and group push are configured separately, group push behavior varies significantly by app, and disabling the integration does not clean up accounts already created. Plan for all three before you start.

Before you begin

• Okta administrator access with permission to manage applications (Super Admin or App Admin for the relevant app).
• A target app that supports SCIM 2.0, ideally with a pre-built Okta Integration Network (OIN) listing. Check the OIN catalog entry for that app — it states whether provisioning and group push are supported. Some apps support user provisioning only, or cap the number of pushed groups.
• A SCIM base URL and API token from the target app, usually generated in its admin console under a "Provisioning" or "Identity" section. Treat the token as a secret; note its expiry policy if the app enforces one.
• Agreement on attribute mappings. Decide which Okta attribute is the unique external identifier (commonly userName mapped to email) and confirm it is unique and stable. Mapping errors here cause failed provisioning or duplicate users.
• A test group and a test user so you can validate without touching production populations.

Configuration procedure

Steps below reflect the Okta Admin Console (Classic Engine) layout as of late 2026; menu labels occasionally shift, so treat names as approximate.

1. Add or open the application integration

In the Okta Admin Console, go to Applications → Applications. Either add the app from the OIN catalog or open your existing integration. Complete sign-on configuration first if you also want SSO — provisioning works independently, but most deployments want both.

2. Enable SCIM provisioning

1. Open the app's Provisioning tab and click Configure API Integration.
2. Check Enable API integration, then enter the SCIM base URL and the API token from the target app.
3. Click Test API Credentials. A successful test confirms network reachability and token validity. If it fails, verify the token wasn't truncated when copied and that the base URL has no trailing path the app doesn't expect.
4. Save.

3. Choose provisioning actions

Under Provisioning → To App → Settings, enable the operations you want Okta to perform: Create Users, Update User Attributes, and Deactivate Users. A conservative rollout enables Create and Deactivate first, validates, then enables Update.

4. Review attribute mappings

In the same To App section, review the attribute mapping table. At minimum, confirm userName, givenName, familyName, and email map to fields the app expects. Remove or leave unmapped any attribute the app's SCIM schema doesn't accept — sending unsupported attributes is a common cause of 400-series provisioning errors.

5. Enable group push

1. Open the app's Push Groups tab.
2. Click Push Groups → Find groups by name and search for your test group.
3. Select the group. Choose whether to create the group in the app immediately or link it to an existing group of the same name.
4. Save. Repeat for additional groups only after the first one validates.

Note: pushing a group pushes its members who are also assigned to the app. Users in the pushed group who aren't assigned to the application won't be provisioned by group push alone.

Validation checks

• Okta side: In the Admin Console, check Reports → System Log filtered by the app, or the app's Provisioning dashboard, for success/failure counts on create, update, and group push events.
• Target app side: In the SaaS admin console, confirm the test user exists with correct attributes, and that the pushed group exists with the expected membership.
• Propagation test: Add a second user to the test group in Okta and confirm the membership change appears in the target app. Group push is typically near-real-time but allow a few minutes; some apps batch updates.
• Deprovisioning test: Remove the test user from the app assignment (or deactivate them in Okta) and confirm the expected behavior in the target — note that "deactivate" in many apps means the account is disabled, not deleted.

Recovery options

• Stop group push without touching users: In Push Groups, set the group's push status to Paused or unlink it. Choose "leave the group in the app" rather than delete if you want to preserve app-side data.
• Pause all provisioning: In Provisioning → To App, uncheck the enabled actions and save. Existing users in the target app remain; cleanup is a separate, manual task or an app-side bulk operation.
• Full removal: Deactivate the API integration and remove the app. Again, accounts already created in the target app persist — export a user list from the target before removal if you need an audit trail.

Limitations to keep in mind

Group push limits, supported operations, and deactivation semantics are defined by each app's SCIM implementation, not by Okta — verify against the app's OIN listing and its own documentation before rollout, as these details change. Nested Okta groups are flattened when pushed. And because token expiry and console layouts vary, re-verify the exact steps against current Okta and vendor docs if you're reading this significantly after publication.